BDI defines Common Roles as the standardized roles for activities in a specific sector or type of supply chain. They form the basis for standardized role-based authorizations, lowering the effort for maintaining authorization rules. .
This type of roles is sector specific, as opposed to BDI Roles that are part of the building blocks
See Policy Agreements.
Sector specific Common Roles
Common roles define operational responsibilities within supply chains, helping to create standardized policies, particularly Data Access Policies.
Each specific sector (type of cargo, modality) has common roles that are well understood and recognized. The same applies to data elements that a role needs to have access to, in order to be able to perform a task.
Defining these common roles (like truck driver, customs agents, inspection agent, forwarder, terminal planner, etc. etc.) reduces the cost of interactions between entities. An undefined role needs custom definitions for the combination role-data access policy: a labour-intensive action.
Managing access rights is simplified by standardization.
Members of different Associations that have different policies per common role, or different roles, will need to align these policies and roles to become interoperable. It is expected that a natural convergence on common roles in a sector will appear over time: Associations will agree upon shared common roles and policies if this benefits their business objectives.
The Professional Qualification Chain is a method that lets other entities verifiy if representatives of the entity that isses the evidence have the required qualifications.
The Professional Qualification Chain registers the relationship between
the digital identity of the owner/controller
the proof of relevant professional qualifications of humans or legal entities
for instance verifiable representations of verifiable credentials
the digital identities of these humans or legal entities
The relationship is transient: as long as it is relevant, and only for relevant qualifications.
The legal implication is that the owner/controlling party assumes accountability and liability for the existence and verification of the relevant Professional Qailification of its representatvies.
The purpose of the building block is to specify:
the interface and structure to issue claims of Professional Qualification (Evidence)
to allow automated verifications of the claim in the Evidence.
The building block is used in Boundary Management, especially Physical Asset Boundaries and Digital Asset Boundaries, for example:
access to a location where specific safety training is required
delivering services that require professional qualifications
use of certified processes (ISO certifications of tools)
means criteria related to an individual's background, including completion of an approved educational program, satisfactory performance on an examination, work experience, testimonials and completion of continuing education.
Personal qualifications are issued by competent organizations to natural person. Examples include universities (education courses), former employers (work experience), governments (VOG statements, driving license), and terminals & chemical plants (health and safety courses).
Process qualifications means criteria related to a process, such as certification of compliance to an ISO standard.
The traditional paper based approach is to collect and store a physical file of the professional qualifications and to present the applicable qualifications when required. This is a cumbersome process and sensitive to fraud as many copies are kept at multiple sources of which varying levels of controls are applied to validate authenticity and validity of the evidence.
A modern approach is to collect the qualifications in an mobile app or a secure card. On request the employee can share the qualifications. Examples include the and the .
The drawback of the app approach is that the different implementations are not interoperable. For example the protocols for retrieving the qualifications from the sources are not standardized. Also the protocols for presenting the qualifications are not standardized.
The (open) European Wallet is an enticing prospect because it will standardize both the retrieving and the presentment of the qualifications as verifiable credentials in the personal wallet of the employee.
The Professional Qaulification Chain transmits only the verificanle representations of specific relevant qualifications.
The following is to be considered:
the personal qualifications are personal data and most likely privacy sensitive. Sharing this data with other organizations is limited to its purpose meaning that anything else not trivial is to be masked.
It requires clear authorization conditions to be provided to the association to ensure that the data is only made available to the organizations that can present clear evidence of the need need to access the data.
are under development. Large scale pilots have started, however focus initially has been on the natural person as civillian in relation to it's state authority and lesser on the 'role' of a natural person as a employee / staff in relation to a Legal Entity / business.
Relevant standards to consider or adopt for the BDI are:
The Verifiable Credential Data Model (). This defines the 'shape' of the claims and belonging metadata that cryptographically prove who issued it. Not the content of the credential itself. This is to be defined in large-scale pilots to strike consensus and find adoption.
The VC can be stored in a Wallet. The BDI supports an exchange is through tokens (JWT's) where for representation evidence to provide a. Specification of the application of the protocol and interfacing is work in progress
The Representation Chain is a building block in the BDI framework. It enables third parties to verify representation mandates — confirming whether a person, legal entity, or automated process is genuinely acting on behalf of another.
A mandate is a formal, authoritative assignment of responsibility from a mandator (the assigning party) to a mandatee (the acting party). It transfers accountability and liability for actions from the mandatee back to the mandator.
To function securely and flexibly across different contexts, the Representation Chain uses Representation Evidence — typically implemented using nested JSON Web Tokens (JWTs). These can be verified both online (e.g., via issuer services) and offline (e.g., on a warehouse floor via a QR scan).
In today’s increasingly interconnected and regulated economy, businesses and authorities are facing a growing need for robust digital proof in everyday interactions. Whether it’s verifying that a subcontractor is authorized to collect a shipment, confirming a driver’s professional qualification, or demonstrating compliance with regulations during an inspection, organizations must often rely on people or systems that act on their behalf. In most cases, liability for these actions lies with the organization, not the individual. This creates a pressing demand for a mechanism that can reliably prove — both legally and practically — that the person or machine performing a task has been officially mandated to do so.
Traditional methods such as paper documents or verbal confirmations are no longer sufficient. A modern solution must be secure, flexible, scalable, and usable in low-tech environments by people with little IT training. It must also support dynamic staffing models and allow independent IT providers to build competitive solutions without vendor lock-in. The JSON Web Token (JWT) standard, originally designed for secure information exchange between systems, offers a strong foundation for such a solution. Its format allows for verifiable digital claims, time-bound validity, cryptographic integrity, and issuer authentication — all critical features for establishing trust in operational contexts.
What makes JWT particularly valuable in this setting is its ability to be embedded within other tokens. This “nesting” allows multiple layers of representation to be encapsulated in a single digital envelope — from a principal organization, through subcontractors, down to the individual or system actually performing the task. Combined with high-trust digital certificates like eIDAS, JWT-based evidence can meet the highest legal standards for electronic signatures while still being compact enough for mobile use.
The approach supports both high-security and user-friendly versions. For example, a delivery driver might receive a QR code and PIN via text, which they present at a loading dock. The system verifies their credentials — offline if necessary — with minimal friction. This combination of simplicity and cryptographic strength makes JWT-based representation not only viable but ideal for logistics, compliance, and other sectors where verifiable delegation and operational practicality must coexist.
The Representation Chain supports both:
Human-to-Machine (H2M) and Machine-to-Machine (M2M) delegation, and
Real-time human access or authority validation, such as in logistics, compliance inspections, or cargo handovers.
It is crucial in:
It provides a verifiable, decentralised mechanism for confirming:
Who gave the mandate
To whom
For what role or task
For what duration
The Representation Chain is conceptually and operationally connected to:
A Representation Chain maintains:
The digital identity of the mandator
The digital identity of the mandatee
The scope of the mandate (role-based, order-based, or otherwise contextual)
The Representation Evidence is typically a nested JWT structure, passed to the mandatee. This token is then presented to a verifying party — such as a loading dock, customs authority, or inspection officer.
The verifier checks the signature chain, timestamps, and optionally contacts the issuer(s) to confirm current validity.
The third party verifier does not need to be a member of a BDI Association, which lowers the barrier for wide-scale adoption and integration.
Supporting business interactions digitally, requires digital proof of authority, particularly in interactions between:
Individual companies
Companies and supervisory/government bodies
The most common scenarios include:
Proof of representation (someone acts on behalf of an organisation)
Transfer of cargo (pickup or delivery confirmation)
Proof of qualifications (such as handling dangerous goods)
People or systems acting on behalf of others must carry digital proof of their mandate. Traditional methods — paper slips, phone calls, or emails — are not scalable, secure, or auditable.
To meet modern requirements, we need a solution that is:
Legally and practically robust
Easy to use in varied operational environments
Broadly applicable across sectors
After 2010, JSON Web Tokens () became a widely adopted standard for representing verifiable claims digitally.
Each JWT contains:
A payload with the actual claims (who, what, when, for whom)
A hash to confirm that the payload hasn’t been tampered with
A digital signature by the issuing party (e.g., via eIDAS or trusted cert)
JWTs support wrapping (embedding), meaning one JWT can include another inside its payload. This enables building multi-level chains of delegation — for example:
There’s no formal limit to the number of layers. For legal-grade use (e.g., cross-border logistics or compliance), JWTs can be signed with high-quality certificates such as eIDAS seals.
This example demonstrates how a chain of representation and delegation is managed digitally when data, is the asset being accessed — and when systems, not people, are the ones performing the action.
A company called SmartWater Solutions manages water quality sensors across industrial facilities. A major client, ChemCo Industries, contracts SmartWater to monitor chemical runoff levels at their facilities. However, SmartWater does not have a data analysis platform robust enough for ChemCo's specific requirements. To meet the SLA, SmartWater subcontracts DeepSignal Analytics, a specialized AI firm, to process and analyze the raw data streams.
Now, DeepSignal’s automated system (an API client) must retrieve sensitive sensor data from ChemCo’s secure telemetry endpoint. However, ChemCo’s API is configured to only accept requests from authorized systems — specifically those acting on behalf of contractual parties.
To make this delegation verifiable and non-repudiable, SmartWater issues a Representation JWT to DeepSignal. This token proves that DeepSignal has been delegated the right to act on SmartWater’s behalf. It includes an embedded JWT from ChemCo to SmartWater, establishing the upstream mandate.
ChemCo Industries issues a JWT authorizing SmartWater Solutions to retrieve and process sensor data on its behalf. The token includes:
Scope (sensor IDs, data types)
Validity window (nbf, exp
The JWT is cryptographically signed by SmartWater and includes ChemCo’s original JWT inside its payload.
When DeepSignal’s system sends a request to ChemCo’s API, it attaches the nested JWT as its digital proof of mandate. ChemCo’s API performs the following checks:
Validates both signatures (SmartWater and ChemCo)
Verifies token expiry and start time
Confirms that DeepSignal's system is the intended subject
If all checks succeed, the API grants access and returns the requested sensor data.
This JWT-based method ensures that:
SmartWater retains liability for DeepSignal’s actions
DeepSignal cannot misuse or forward the token, as the claims are specific and signed
ChemCo has an audit trail of who requested what data and on whose authority
This example illustrates how a chain of representation is securely and digitally established using embedded JWTs in a real-world logistics setting.
A large industrial buyer has purchased hydrofluoric acid and the supplier — Acne Inc. — arranges for the pickup to occur at Lets-B-Chemical. However, Acne does not have its own transport capacity and therefore contracts the trusted logistics firm Van Gend & Loos to execute the pickup and delivery.
Van Gend & Loos does not have a truck available on the required date. Instead, it chooses to subcontract the pickup task to De Snelle Visser, a regional carrier already scheduled to pass by Lets-B-Chemical. Dolly Driver, an employee of De Snelle Visser, is tasked with executing the collection.
Now Dolly must be able to prove the following:
That she has a valid, authorized assignment from her employer De Snelle Visser.
That De Snelle Visser was subcontracted by Van Gend & Loos.
That Van Gend & Loos was originally contracted by Acne Inc.
At the pickup location, Lets-B-Chemical needs to verify her mandate and qualifications before releasing the acid. This must be done quickly, securely, and ideally without needing complex systems or manual calls. To enable this, a chain of JWTs is created and passed down from Acne Inc. to Dolly Driver.
Acne Inc. issues a signed JWT that authorizes Van Gend & Loos to collect the hydrofluoric acid.
Van Gend & Loos issues a JWT to De Snelle Visser, embedding Acne's original JWT inside. This proves that Van Gend had authority to subcontract and passes the responsibility trace.
De Snelle Visser creates a JWT embedding both upstream tokens and includes Dolly's:
Dolly arrives at Lets-B-Chemical and presents a QR code on her mobile phone. This QR code contains the fully nested JWT. The security officer scans it using a standard or BDI-enabled app.
The system:
Verifies the cryptographic signature chain
Checks timestamps (validity, expiry, issuance)
Confirms Dolly’s identity and employer
If all criteria are met, the acid is released.
This chain-of-proof allows the liability and mandate to be fully tracked and provable, including post-facto audits. The information can be viewed via a link (e.g., "bdidrop.link/124V") or through integration with back-office systems.
The structure is robust enough for secure transport of sensitive cargo and simple enough to be used by temporary staff with minimal digital training.
The most common transaction in logistics is the handover of goods (cargo on its way through the supply chain) between entities. Part of the handover is associated with trade (buyer-seller), part of the handover is about liability (transporter taking cargo on board of a vessel, plane, railcarriage or truck).
The "Digidrop" approach to executing transactions (such as transfer of goods) shifts the legal "signing" of a transaction to IT-systems on behalf of the companies involved. The human involvement is supportive and indirect, instead of acting as a representative of the entity. The IT-systems involved act as the representatives of the legal entities involved.
This approach circumvents the issues and obstacles that rise if humans need digitally "sign" a transaction. The Digidrop document outlines the approach.
BDI’s method accounts for non-ideal environments — e.g., no internet, broken devices, or limited IT skills. Many (SME) actors in logistics are not yet able to integrate themselves in a more advanced IT-interaction framework such as the BDI.
In such a case the most valuable piece of information that needs to be digitally available is the visbility of a handover event. A fallback methode has been designed for such use cases, minimizing the requirements. Such a method is not a replacement of the traditional "paper-based" processes: it only creates more visbility in the supply chain.
The driver receives a QR code and PIN via WhatsApp or SMS
The warehouse scans the QR code using the DigiDrop app
The driver verbally gives the PIN to authorize data viewing
This process:
Works offline
Prevents showing data without consent (PIN as consent barrier)
Adds traceability
If QR scanning fails:
A short link is provided to the warehouse via text
They can type this into a browser
The PIN unlocks the relevant information
If a warehouse does not use DigiDrop:
The driver presents the URL and PIN
A trusted backend (e.g., TMSX) provides a basic web interface
Security is reduced, but functionality is preserved
The Representation Chain provides a flexible, secure, and verifiable method for proving authority in business interactions — whether digital or physical. Its implementation via JWTs is:
Scalable
Legally robust
Compatible with low-tech environments
Designed for both machines and people
Combined with fallback workflows and hybrid adoption pathways, this method is ready for real-world logistics, compliance, and digital service chains.
BDI Edge Agreements
Documents
With what professional qualifications (if applicable)
Professional qualifications
Optional links to issuers for revocation or validation
A jti (token ID) for revocation checks
SmartWater Solutions issues a second JWT to DeepSignal Analytics, embedding the ChemCo JWT. It contains:
DeepSignal’s system identifier (API client ID or server public key reference)
Constraints on data types, endpoints, or frequency
A clear mandate scope (e.g. "read-only access to zone A sensor logs")
Optionally, looks up the token's jti in ChemCo’s revocation list or representation register
Identity details
Employment role
ADR (dangerous goods) certification
Device-specific metadata (e.g. IP address, vehicle license)
Optionally contacts the issuer (e.g., Acne or Van Gend) to verify token revocation status
The warehouse confirms and releases the goods