Identification, Authentication, Authorization In A World Of Delegated Authority

"Trust, but verify."

Ronald Reagan, 40th President of the United States (1911–2004)

Pillar I – Identity Foundation – Part 2 of 3:

By Stephan Wolf, Chair of the Board of Trustees at Verifiable.Trade Foundation

May 2026

If identity is the structured description of a subject within a context, then the next question is straightforward: How do systems actually use identity in real interactions? This is where three concepts come into play: identification, authentication, and authorization. They are often used interchangeably, yet they describe fundamentally different functions. Confusing them is one of the main reasons why digital systems in trade, finance, and supply chains remain fragmented and inefficient.

Identification answers the question: who or what is involved in this interaction. It is the act of referencing an identity within a given context. A Legal Entity Identifier points to a company. A shipment reference points to goods in transit. A name or credential points to a person. Identification is about establishing a reference, nothing more.

Authentication answers a different question: can this claim be trusted. It is the process of verifying that a presented identity is genuine. A digital signature, a credential, or a cryptographic proof allows a system to confirm that the party presenting the identity is indeed in control of it. Authentication creates confidence that the interaction is not fraudulent.

Authorization goes one step further. It answers the question: what is this actor allowed to do. This is where most real-world complexity begins.

A bank receives a payment instruction. The signatory is listed as finance officer of the counterparty. The instruction is formatted correctly, the LEI matches, the amounts are within threshold. Payment is released.

What the bank did not and could not verify: that person's authorization as finance officer had been revoked three days earlier following an internal restructuring. The system that processed the payment had no way of knowing. The role still existed in the integration layer. It simply no longer reflected reality.

The Authorization challenge

In business environments, actions are rarely performed by isolated individuals. They are performed by people acting on behalf of organizations, within specific roles, and under specific conditions. A warehouse clerk confirms delivery. A finance officer approves payment. A logistics provider employee updates shipment status. None of these actions derive legitimacy from personal identity alone. They derive legitimacy from delegated authority.

The urgency of getting authorization right has never been greater. Until recently, a flawed authorization model was an operational problem. A human could exercise judgment, flag an anomaly, escalate. That safety net disappears when the actor is an AI agent executing a workflow autonomously on behalf of an organization. An agent does not hesitate. It does not notice that the role it was granted six months ago no longer reflects the current organizational structure. It acts on what the system tells it, at machine speed, at scale. The question is no longer whether your authorization model is efficient. It is whether it is safe.

Authorization is therefore not static. It is dynamic, contextual, and often ephemeral:

• A person may be authorized to approve payments up to a certain threshold, but only within a specific time window.

• A delivery confirmation may only be valid at a specific location and for a specific shipment.

• A financing instruction may depend on the prior verification of a delivery event.

A global buyer works with a supplier across three touchpoints: procurement, logistics, and trade finance. In the ERP, the supplier is registered under a local tax number. In the freight platform, they appear under a trading name. In the bank's KYC record, they are registered as a parent entity in a different jurisdiction.

When a dispute arises over a delivery confirmation and someone needs to verify who actually had authority to sign, there is no single authoritative answer. Each system is internally consistent. None of them agree with each other.

And it doesn’t stop there. In many cases, authorization is granted for a single transaction and expires immediately after. This creates a fundamentally different requirement for digital systems. Authorization cannot be treated as a fixed permission stored in a central database. It must be evaluated in real time, based on context, relationships, and the current state of the transaction.

Most existing systems struggle with this. They embed authorization logic within applications, leading to rigid role models, duplicated access controls, and complex integration layers. Each platform defines its own rules, its own roles, and its own interpretation of authority. As a result, the same person may need to be onboarded multiple times, assigned multiple roles, and re-authorized across systems that do not recognize each other.

The Authorization Triad

Every digital interaction in trade involves three distinct questions. Conflating them is the root cause of fragmented, inefficient systems.

·           Who is involved in this interaction? That is identification.

·           Can I trust the claim being made? That is authentication.

·           Is this actor empowered to take this action? That is authorization.

Getting all three right, separately and in sequence, is the foundation of interoperable digital trade.

This is not a technology problem. It is a conceptual problem. The root cause lies in how identity, authentication, and authorization are structured. When identity is tied to systems, authorization becomes tied to systems as well. Delegation becomes difficult to express across organizational and technical boundaries. Trust becomes fragmented.

A different approach starts by separating these concerns and making them interoperable. In such a model, identification is handled through globally resolvable identifiers that point to structured identity data. Authentication is handled through cryptographic mechanisms that allow any party to verify claims independently. Authorization is expressed through verifiable relationships between actors, capturing who is allowed to act on behalf of whom, in which role, and under which conditions.

An AI agent is authorized to confirm delivery events on behalf of a logistics operator. Its authorization was issued for a specific contract, valid for 90 days. The contract completes. The agent's credential is not revoked; it simply sits, dormant, in the system.

Six months later, a new workflow reactivates a similar process. The agent acts. The system accepts it. No human reviewed whether the authority still applied. The credential had not expired on paper. The business context in which it was granted no longer existed.

The stakes extend well beyond operational friction.

1. Fraud risk is structural:

When authorization is stored inside a platform rather than expressed as a verifiable credential, there is no reliable way to confirm at the moment of action that the authority being exercised is real, current, and scoped correctly.

2. Liability risk is contractual:

In cross-border trade, an action taken on the basis of an authorization that cannot be independently verified is an action whose legal validity is permanently in question.

3. Audit risk is regulatory:

Demonstrating that controls were operative at a specific moment in time requires more than a platform log entry. It requires a verifiable, time-stamped record of authority that exists independently of the system that acted on it. Inefficiency is the symptom. These three risks are the disease.

Verifiability is key for establishing trust

This is where the concept of verifiable credentials and role-based attestations becomes critical. Instead of storing permissions inside applications, organizations can issue cryptographically verifiable statements. A company can attest that a specific person is authorized to act as warehouse clerk. A bank can attest that a company has a valid account relationship. A freight forwarding agent can attest to the status of a shipment. These attestations can be presented, verified, and combined at the moment an action is performed. Authorization becomes something that is proven, not something that is assumed.

This approach also allows for fine-grained and time-bound permissions. A credential can be issued for a single transaction, a specific time frame, or a defined business condition. Once the condition is fulfilled, the authorization naturally expires. There is no need for manual revocation processes or complex access management systems.

In a world of delegated authority, this is essential. Authority is not a static property. It is a dynamic relationship that evolves with every interaction.

The implications for global trade are significant

Consider a simple scenario. A shipment is delivered. The delivery event is confirmed by a warehouse clerk acting on behalf of the buyer. This confirmation triggers a financing process. A bank verifies not only the shipment data, but also the authority of the person who confirmed it. Payment is then initiated based on this chain of verifiable events. Each step relies on identification, authentication, and authorization working together across domains and systems, but not being confused with each other.

Identification ensures that all parties and objects are clearly referenced. Authentication ensures that all claims are trustworthy. Authorization ensures that each action is legitimate within its business context. When these elements are structured as interoperable components rather than system-specific functions, a new architecture becomes possible. This is the foundation of a protocol-based approach such as ISTTP.

By detaching identity and authorization from individual platforms and expressing them as verifiable, portable, and context-aware constructs, ISTTP enables participants to interact without needing to pre-integrate their systems. Authority can be delegated across organizational boundaries. Permissions can be evaluated in real time. Trust can be established directly between parties, based on cryptographic proof rather than system-level assumptions.

This fundamentally changes how digital trade systems operate

Instead of managing users and permissions within isolated platforms, organizations manage relationships and authority in a shared, interoperable layer. Instead of duplicating onboarding and access control, participants reuse verified identity and role information across interactions. Instead of static permissions, they operate with dynamic, context-driven authorization. The result is not just improved efficiency. It is a shift from system-based trust to data-based trust.

Understanding identity was the first step. Understanding how identity is used in identification, authentication, and authorization is the next. Together, they form the operational backbone of any digital interaction.

In a world where authority is constantly delegated, transferred, and verified, getting this right is not optional. It is what enables systems to move from coordination to true interoperability.

There is one further development that makes this conversation urgent rather than theoretical. As AI agents begin to execute trade workflows autonomously, the question of delegated authority moves from an operational concern to a governance one. Who authorized the agent? Under what conditions? For how long? If an AI agent confirms a delivery, triggers a financing event, or initiates a cross-border payment, the organization behind it remains legally and contractually accountable for that action. In a world where authority is exercised at machine speed, across organizational boundaries, without a human in the loop, the ability to prove that authorization was valid, contextually appropriate, and properly scoped is not a technical nicety. It is the foundation of corporate accountability.

At the same time, another shift is taking place. From the outside, an AI agent may increasingly be indistinguishable from a human decision-maker. Counterparties, platforms, regulators, and even other AI systems may interact with algorithmic actors as if they were organizational representatives exercising legitimate authority. In practical terms, AI algorithms are becoming subjects of decision-making within commercial processes. They negotiate, approve, trigger, reject, and instruct. But unlike humans, they do not possess inherent legal identity or accountability. The responsibility always traces back to the legal entity that deployed, authorized, and governed them.

This creates a profound new requirement for digital trade and digital commerce infrastructure. It is no longer sufficient to identify only organizations or individuals. Systems must also be able to identify the authority context under which an AI agent operates: who delegated authority, what permissions were granted, what constraints apply, which policies govern its actions, and whether those permissions were still valid at the exact moment the action occurred.

Without this, autonomous commerce will scale operational risk faster than operational efficiency. With it, organizations can enable AI-driven automation while maintaining legal accountability, auditability, and trust across ecosystems.

Glossary of Key Terms

Verifiable.Trade Blog Series — Identity, Authentication, and Authorization in Digital Trade

This glossary defines the core technical and conceptual terms used throughout the Verifiable.Trade blog series. It is intended for readers who may be encountering these terms for the first time, as well as for practitioners who want a precise, source-referenced definition. Each entry links to its authoritative source.

Term                           

Definition and Source

Identifier

A label or code used to reference an entity within a system or context. An identifier is not identity itself; it is a pointer to identity data. The same entity may have multiple identifiers across different systems.Source: ISO/IEC 24760-1:2019 – A framework for identity management

Identity

The structured set of attributes that describe an entity within a given context. Identity is relational and contextual: the same entity may have different identity representations depending on the context in which it is referenced.Source: ISO/IEC 24760-1:2019 – A framework for identity management

Identification

The act of referencing an entity within a given context using an identifier. Identification establishes which entity is involved in an interaction; it does not verify the claim or establish authority.Source: NIST SP 800-63-3 – Digital Identity Guidelines

Authentication

The process of verifying that an identity claim is genuine — confirming that the party presenting the identity is in control of it. Authentication creates confidence that an interaction is not fraudulent, typically through cryptographic mechanisms such as digital signatures.Source: NIST SP 800-63-3 – Digital Identity Guidelines

Authorization

The process of determining what an authenticated actor is permitted to do within a given context. Authorization is dynamic and contextual: it depends on role, time, conditions, and the current state of a transaction. It is distinct from both identification and authentication.Source: NIST SP 800-63-3 – Digital Identity Guidelines

Verifiable Credential (VC)

A cryptographically signed digital statement made by an issuer about a subject. Verifiable credentials allow any party to independently confirm the authenticity and integrity of the claim without contacting the issuer. They are a core building block of decentralized identity infrastructure.Source: W3C Verifiable Credentials Data Model 2.0

Verifiable Identifier

An identifier that can be cryptographically verified as belonging to its controller, without reliance on a central registry. Verifiable identifiers enable trust to be established directly between parties based on proof rather than assumption.Source: W3C Decentralized Identifiers (DIDs) v1.0

Decentralized Identifier (DID)

A type of globally unique identifier that is created, owned, and controlled by the subject itself, without requiring a centralized registration authority. DIDs are resolvable to a DID Document containing public keys and service endpoints, enabling cryptographic verification.Source: W3C Decentralized Identifiers (DIDs) v1.0

Legal Entity Identifier (LEI)

A 20-character alphanumeric code that uniquely identifies a legal entity participating in financial transactions. The LEI is issued under the Global LEI System (GLEIS), overseen by the Global Legal Entity Identifier Foundation (GLEIF), and is the internationally recognized standard for legal entity identification.Source: GLEIF – Global Legal Entity Identifier Foundation

Revocation

The process of invalidating a previously issued credential or authorization before its natural expiry. In verifiable credential systems, revocation is managed through cryptographic mechanisms such as revocation lists or status registries, allowing any verifying party to check whether a credential remains valid at the moment of use.Source: W3C Verifiable Credentials Data Model 2.0 – Validity Checks

Delegated Authority

The grant of permission for one party to act on behalf of another within defined limits and conditions. In digital trade, delegated authority is a core concept: individuals act on behalf of organizations, agents act on behalf of principals, and authorization must express these relationships in a verifiable and time-bound way.Source: GLEIF vLEI Ecosystem Governance Framework

ISTTP (International Secure Trade and Transport Protocol)

An open, protocol-based infrastructure for digital trade that enables parties to interact across organizational and system boundaries using verifiable identity, delegated authority, and cryptographically secure trade objects. ISTTP is designed to complement existing standards such as UN/CEFACT message templates and EN 16931.Source: Verifiable.Trade Foundation

KERI (Key Event Receipt Infrastructure)

A decentralized key management protocol that enables cryptographically verifiable identifiers without reliance on a blockchain or central registry. KERI uses a self-certifying identifier model in which control is established and transferred through a verifiable log of key events.Source: Key Event Receipt Infrastructure (KERI) White paper

ACDC (Authentic Chained Data Containers)

A verifiable credential format built on KERI that supports chained, composable attestations. ACDCs enable selective disclosure, graduated disclosure, and the construction of trust chains across multiple issuers and verifiers without centralized infrastructure.Source: Trust over IP Foundation – ACDC specification

vLEI (Verifiable Legal Entity Identifier)

A cryptographically verifiable form of the LEI that extends the Legal Entity Identifier standard with organizational role credentials. The vLEI allows legal entities to issue verifiable credentials to individuals acting in official capacities, enabling machine-verifiable representation of organizational authority.Source: GLEIF – Introducing the Verifiable LEI

KYC (Know Your Customer)

A regulatory and compliance process requiring financial institutions and other regulated entities to verify the identity of their clients and assess the risk of the relationship. KYC processes typically involve identity verification, beneficial ownership checks, and ongoing monitoring.Source: Financial Action Task Force (FATF) – Guidance on Digital Identity

Cryptographic Proof

A mathematical mechanism that allows one party to demonstrate knowledge or control of information without revealing the information itself, or to prove the integrity and origin of a message. In digital identity systems, cryptographic proofs are used to verify credentials, authenticate parties, and confirm that data has not been tampered with.Source: W3C Verifiable Credentials Data Model 2.0 – Proofs

Object-Based Trust

A trust model in which integrity and authenticity are attached to the data object itself rather than provided by the network or platform through which it is transmitted. Object-based trust enables data to be verified independently of the channel through which it was received, enabling interoperability across platforms and jurisdictions.Source: Verifiable.Trade Foundation

MLETR (Model Law on Electronic Transferable Records)

A model law developed by UNCITRAL that provides a legal framework for the use of electronic transferable records, including bills of lading, bills of exchange, and promissory notes. MLETR establishes the legal equivalence of electronic and paper-based transferable records where certain functional requirements are met.Source: UNCITRAL – Model Law on Electronic Transferable Records (2017)

EN 16931

A European standard that defines the semantic data model for the core elements of an electronic invoice. EN 16931 specifies the meaning and format of invoice data to enable interoperability across e-invoicing platforms within the European Union and beyond.Source: CEN – EN 16931 Electronic Invoicing Standard

This glossary will be updated as the blog series develops. Terms specific to individual pillars will be added as each article is published. For questions or suggested additions, contact the Verifiable.Trade Foundation at www.verifiable.trade/contact.

© 2026 Verifiable.Trade Foundation