DID AuthZ

DID AuthZ (Decentralized Identifier Authorization) is a framework that extends the authentication capabilities of DIDs to manage authorization—the process of determining what an authenticated entity is permitted to do. While DID AuthN (Authentication) proves "who you are" using cryptographic proofs linked to a DID, AuthZ answers "what you can access." It leverages Verifiable Credentials (VCs)—tamper-evident digital claims—to encode permissions, roles, or attributes, which are presented and verified in a decentralized manner. This shifts control from centralized authorization servers to the individual identity holder.

The technical foundation of DID AuthZ often involves the Authorization Capability (ZCAP) model, where a capability—a cryptographically signed, delegatable token—grants specific access rights to a resource. A user presents a relevant Verifiable Credential to a resource server (e.g., an API or data vault), which verifies the credential's signature and checks the contained authorization claims against its access control policy. This process is defined in specifications like the Decentralized Identifier Authorization (DID AuthZ) draft by the W3C Credentials Community Group, ensuring interoperability across different systems.

Key benefits of this model include user sovereignty, as individuals manage and consent to the use of their credentials; fine-grained permissions, where access can be scoped to specific actions and durations; and privacy preservation, through the use of selective disclosure and minimal data exposure. It eliminates reliance on a central policy decision point, reducing bottlenecks and single points of failure. Common use cases include accessing secure APIs, sharing medical records with a clinic, or granting temporary entry to a smart lock, all controlled by the user's digital wallet.

Implementing DID AuthZ requires a stack of complementary technologies. The holder of a DID uses a wallet to store and present credentials. The issuer (e.g., a university or employer) signs and issues VCs with authorization claims. The verifier (the resource server) must resolve the holder's DID to a DID Document to obtain public keys for verification and evaluate the presented credentials against its policies. Standards like Verifiable Credentials Data Model, DID Core, and ZCAP-LD provide the necessary building blocks for a secure and interoperable ecosystem.

Compared to traditional OAuth 2.0, DID AuthZ offers a fundamental architectural shift. OAuth relies on a centralized authorization server that issues opaque tokens referencing centralized user accounts. In contrast, DID AuthZ uses self-sovereign, bearer-authority tokens (capabilities) tied to a decentralized identifier, with policies embedded in the verifiable credentials themselves. This enables offline verification, peer-to-peer delegation, and audit trails that are cryptographically verifiable, making it particularly suited for decentralized applications, IoT networks, and trust-minimized environments.

The term DID AuthZ is a portmanteau and technical abbreviation derived from two core concepts in identity and access management: Decentralized Identifiers (DIDs) and Authorization (AuthZ). It explicitly distinguishes authorization from the separate process of authentication (AuthN), a critical division in security architecture. The term emerged in the mid-to-late 2010s alongside the development of the W3C Decentralized Identifiers specification, as developers sought to define how verifiable credentials and DIDs could be used to grant specific permissions in a decentralized manner, moving beyond simple login.

The DID component originates from the broader movement toward self-sovereign identity (SSI), which aims to give individuals control over their digital identities without reliance on central authorities. A DID is a unique, persistent identifier created, owned, and controlled by the subject (e.g., a person, organization, or thing) and is typically recorded on a verifiable data registry like a blockchain. This provides the foundational, cryptographically verifiable "who" for the authorization process.

The AuthZ component has its roots in traditional access control models like Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), but adapts them for a decentralized context. Instead of a central server checking permissions in a database, AuthZ in a DID-based system involves presenting cryptographically signed verifiable credentials that contain claims (e.g., "is over 18," "holds a professional license") to a verifier. The verifier uses the rules of a trust framework or policy to decide if the presented credentials grant access to a resource.

The fusion into DID AuthZ represents a paradigm shift from centralized permission silos to a user-centric, interoperable model. It describes the protocol flow where a holder of a DID uses verifiable credentials to prove not just their identity (AuthN), but also their right to access a specific service or perform an action (AuthZ). This is often implemented using standards like OAuth 2.0 and OpenID Connect (OIDC) extended for decentralized identity, sometimes referred to as OIDC4VC or SIOP (Self-Issued OpenID Provider).

In practice, a DID AuthZ flow might involve a user presenting a university-issued verifiable credential (proving student status) from their digital wallet to access a research database, with the resource server verifying the credential's signature and validity against the issuer's DID on a blockchain. The term thus encapsulates the entire stack—from the foundational DID and verifiable data registry to the presentation exchange and policy evaluation—that enables trusted, machine-verifiable authorization in a decentralized ecosystem.

DID AuthZ is a framework that extends the concept of Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) into the authorization layer. It enables a Resource Owner (the user) to grant specific permissions to a Client application, which can then present proof of this authorization to a Resource Server. This process is distinct from traditional OAuth 2.0, as it leverages cryptographically verifiable, self-sovereign credentials instead of opaque tokens issued by a central authorization server. The core components are defined in the W3C Verifiable Credentials Data Model and related Decentralized Identity Foundation (DIF) specifications.

The workflow typically involves three key interactions. First, a Client requests access to a protected resource, presenting its own DID. Second, the Resource Server responds with an Authorization Request, specifying the required credentials or claims (e.g., "over 18," "has subscription tier X"). Third, the Resource Owner uses a Wallet or Agent to review this request, select the appropriate Verifiable Credentials from their digital wallet, and create a Verifiable Presentation that is signed and sent back to the Client. This presentation serves as the proof of authorization.

The Resource Server then verifies the authorization by checking several cryptographic proofs: the DID signatures on the presentation and the underlying credentials, the status of the credentials (ensuring they are not revoked), and whether the claims satisfy the policy. This verification is done against public DID Documents and Verifiable Data Registries (like blockchains), eliminating the need to call a central server to check token validity. This architecture enables offline verification and privacy-preserving selective disclosure of attributes.

A primary use case for DID AuthZ is decentralized API access control. For instance, a user could grant a data analytics dashboard permission to read their financial transaction history from a bank's API for one week. The dashboard presents a Verifiable Presentation containing a credential issued by the user authorizing this specific scope and duration. The bank's API server verifies this presentation directly, without needing to coordinate with the dashboard's backend or a central OAuth server, streamlining integration and enhancing user agency over their data.