Executive Summary

In multi-party trade flows, every participant relies on its own IAM stack with a different Identity Provider (IdP) – Okta here, Ping there, Entra ID somewhere else, sometimes Auth0 or bespoke stacks.
Historically, the industry tried two imperfect fixes:

• At best: federation projects – complex, costly, and slow to implement.
• At worst: forcing users to juggle multiple logins across different portals – insecure and a nightmare for user experience.

TradeVeris takes a different path – a Verifiable Credential (VC)-first approach. Instead of stitching IdPs together or multiplying passwords, we accept cryptographic proof (e.g., vLEI) at the system boundary, verify it locally, and convert it into the tokens and roles your apps already use – without cross-IdP federation or login sprawl.

Introduction: Digitalising Trust Across Organisational Boundaries

Global trade is full of moments where two (or ten) companies must trust who’s on the other side and what authority they have; often just for a few days, a specific container, or a single document exchange.
For years, the workaround was multiple usernames and passwords for every portal, creating friction, weak security, and poor auditability.

A VC-first model changes that: each relying party verifies portable, cryptographically signed credentials and issues its own short-lived tokens for local apps.

At the heart of TradeVeris’s approach sits vLEI (verifiable Legal Entity Identifier): a digitally verifiable credential anchored in the global LEI system and governed by GLEIF, with role credentials for official capacities (e.g., OOR, ECR). vLEI is built on ACDC and uses did:webs for DID resolution – delivering event-based key management and portability in a ledger-agnostic model that can anchor on distributed systems or blockchain where required.

Why Traditional Approaches Struggle

• Scale & churn: Dozens or hundreds of counterparties, with lanes and partners changing weekly. Maintaining multiple logins or federating every IdP pair doesn’t scale.
• Heterogeneity: Okta, Ping, Entra ID, Auth0 and bespoke IAMs coexist; versions and protocols differ (SAML/OIDC/WS-Fed).
• Governance & liability: Who asserts roles? Who deprovisions? Cross-company entitlement management becomes hard to audit.

The TradeVeris Approach: VC → OIDC/OAuth Bridge at Each Boundary

TradeVeris deploys a verifier/broker next to each portal or API:

1. Presentation
   The user (or agent) shares a vLEI together with a purpose credential via OIDC4VP/SIOPv2 – standardised wallet flows for secure VC exchange. Alternatively, credentials can be shared via KERI-based protocols using a KERI-enabled wallet, ensuring event-driven trust and portability.
2. Verification & Mapping
   The verifier validates cryptographic signatures, checks trust chains (GLEIF, QVIs, sector issuers), and confirms credential integrity. Once verified, claims are mapped to local RBAC/ABAC roles, aligning with existing IAM policies without external dependencies.
3. Token Issuance
   After verification, the IdP issues a standard OIDC ID token or OAuth access token that applications already understand – enabling seamless integration with existing IAM stacks and eliminating cross-company federation.

Human Authentication & Holder Binding

VC presentation alone isn’t enough – you need to know the actual holder is present and acting.
TradeVeris pairs VC presentation with FIDO2/WebAuthn, delivering phishing-resistant MFA and cryptographic holder binding – the gold standard for proving “who” is acting in real time.

did:webs + KERI Trust + eIDAS QTSP Signature

TradeVeris uses did:webs for DID resolution and KERI’s event-based trust model, which is ledger-agnostic – anchoring can be implemented on distributed systems or blockchain for added immutability.
Credential interactions are logged in an event-based trust model, creating a tamper-evident audit trail.
For high-stakes actions – like signing an eCMR or a bill of lading – we augment this with an eIDAS QTSP signature, providing qualified electronic signature assurance. This delivers unequivocal evidence of the actual holder, cryptographically bound to the credential and the event history.

Concrete Walkthrough: EU Port Import Scenario

From arrival notice to gate out, each party uses its own IAM but accepts VC-backed proof at the boundary. No IdP federation is set up between companies; no multiple logins; each system issues local tokens after verifying the VC set:

• PCS/terminal/carrier portals: Importer or broker presents vLEI + role; portals validate via the VC→OIDC bridge and issue an OIDC session.
• Customs (ICS2 regime): Declarant presents importer’s vLEI + due diligence authority; gateway validates and emits tokens for customs APIs.
• Gate pickup: Carrier dispatch issues a short-lived pickup authorisation bound to the driver and container; terminal verifies at gate and grants access.
• eCMR: During pickup and delivery, eCMR is updated and signed; the ecosystem moves to interoperable digital notes accepted cross-border.

This pattern scales because each relying party trusts credential issuers and cryptography – not a partner’s IdP configuration or a patchwork of passwords.

Security & Governance Benefits

• Phishing-resistant authentication at the point of presentation (FIDO2/WebAuthn).
• Holder binding ensures the presenter actively controls the credential.
• Least privilege via short-lived purpose credentials bound to shipment/time/location.
• Auditability: Signed event logs of “who acted, for whom, under what authority.”
• Operational simplicity: Accept the same credential types everywhere; no fragile IdP trust meshes or login sprawl.

Takeaway

You don’t need to knit every partner’s IdP into yours – or force users to juggle multiple passwords. Accept verifiable credentials (especially vLEI) via a VC→OIDC/OAuth bridge at each boundary, pair them with FIDO2 holder binding, and augment with eIDAS QTSP signatures for high-assurance actions.
Portable trust, strong authentication, and compliance – without the long tail of federation projects or login fatigue.