A decentralized identifier has a method name and a method-specific identifier after its did prefix. Resolving it produces a DID document describing verification methods and potentially services. Its subject may be a person, organization, device or other entity. The controller can update the document according to the method, and need not be the subject. DID Core therefore describes relationships and control mechanisms, not a universal identity card. It does not mandate a blockchain, a cryptocurrency or a particular consensus algorithm.

A DID method supplies the concrete creation, reading, updating and deactivation rules.

The DID use-case document explains why that separation matters. Its scenarios include education, prescriptions, digital executors and secure communication, rather than only financial accounts. An identifier that survives a change of service provider could make a long-lived relationship less dependent on one website. Persistence is a design objective, however, with consequences for method selection and operation. Someone using an identifier needs to understand where its current control information comes from and what keeps that information available.

The document is a collection of motivating scenarios. Its examples do not establish that every proposed workflow has already been deployed or that every method supplies the same recovery guarantees.

The Verifiable Credentials model separates an issuer, a holder and a verifier. A credential contains claims about a subject; a presentation carries credentials or information derived from them. Cryptographic verification establishes an authentic, current statement under the selected mechanism, not the truth of its contents. A verifier still decides whether an issuer is authoritative for the claim. A university credential and an unknown website's imitation can have equally well-formed data.

The model also does not supply a complete authorization framework: successfully presenting information does not automatically grant access to a service.

The official use cases make this concrete through fictional educational and age-checking examples. A learner wants to carry a transcript between institutions without repeatedly asking an intermediary to distribute it. A person proving that they are over an age threshold may not need to disclose their exact birth date, address or document number. These are different requests, even when the same underlying credential can answer both. The holder is not necessarily the subject, which allows delegated situations but requires the surrounding system to understand that relationship.

The point of the scenarios is to identify requirements for portable evidence, not to turn every existing paper process into an identical digital interaction.

Controlled Identifiers 1.0 describes controller documents and the lifecycle of verification methods. Rotation replaces a method for future use; revocation responds to circumstances such as compromise. Historical verification introduces a harder question: which method was authorized when the proof was made? An implementation may need trustworthy historical state and evidence of time, neither of which appears merely because a current document can be fetched. If an attacker has a signing key, their signatures can be indistinguishable from legitimate signatures before the compromise is addressed.

Recovery procedures, preserved history and clear effective times consequently affect whether a credential remains useful years later. A new key alone does not reconstruct missing evidence about an old signature.

Verifiable Credential Data Integrity defines a framework for protecting documents through named cryptographic suites. A suite specifies transformations, hashing and proof operations rather than leaving implementers to improvise incompatible signing rules. The proof purpose also matters: a key authorized for one relationship should not silently be accepted for another. Versioned contexts and integrity checks help control dependencies involved in interpreting a signed document.

This architecture permits different algorithms while retaining an explicit description of how verification should work. Interoperability still requires both sides to support the relevant suite and its processing rules. Merely recognizing a proof property is not equivalent to successfully checking the proof.

The JOSE and COSE Recommendation provides another family of securing mechanisms. JOSE uses the JSON-oriented signature ecosystem, while COSE supports compact CBOR representations. Selective-disclosure mechanisms can reveal chosen information without transmitting every original claim. These formats should be selected as part of a concrete implementation profile, with exact media types and verification requirements. The specification explicitly rejects treating an unsecured alg value of none as integrity protection.

A familiar token-shaped string is therefore insufficient evidence that a credential is secured. Data representation, signature validation and the meaning of a claim are separate pieces of the exchange, and changing the envelope does not eliminate the need to evaluate any of them.

Bitstring Status List 1.0 addresses the privacy cost of checking a separate URL for each credential. Such a request can tell an issuer exactly which credential is being presented. A shared compressed list instead groups many status entries, letting a verifier retrieve a larger set rather than identify one person in the request. Status purposes include suspension and revocation; they are not interchangeable. The specification also distinguishes a credential's status from the continued truth of an underlying achievement.

Revoking a compromised digital diploma need not erase the graduate's degree. List size, caching and deployment choices remain relevant to correlation: a shared format helps reduce a particular tracking opportunity but does not make every verifier interaction anonymous.

Research continues beyond the standardized list. In August 2026, Patrick Herbke and co-authors published ShadowPath, a proposal that moves status lookup to the holder and uses a zero-knowledge proof against a verifier-selected registry root. Its purpose is to hide recurring lookup metadata that could connect presentations. The reported comparison of sparse Merkle and Verkle approaches also challenges the assumption that a shorter authenticated path necessarily produces a cheaper proof. These are research results under an explicit model, not a new W3C Recommendation.

The paper excludes issuer-verifier collusion and synchronization traffic from its stated privacy guarantee. Its contribution is a concrete alternative and evaluation that can be examined, rather than a claim that revocation privacy has been solved for every device and adversary.

The BBS cryptosuite work provides selective disclosure and unlinkable derived proofs. Instead of repeatedly presenting an identical signature artifact, a holder can derive a proof for a selected disclosure. The distinction between a base credential and a derived presentation is central to that design. As reviewed on October 2, 2026, the published document is a September 10 Candidate Recommendation Draft, not a completed Recommendation. Optional anonymous holder binding and credential-bound pseudonyms are identified as at-risk features with further dependencies and implementation requirements.

A product claiming support should identify its exact profile and supported features. The candidate label is meaningful information for interoperability planning, particularly when two wallets implement different generations of the work.

W3C's Privacy Principles supplies a broader test for the surrounding service. Its May 2025 Statement argues for limiting transferred data to people's goals and interests, with granular controls over personal information. That applies even to information not initially considered identifying or sensitive. A wallet can offer selective disclosure while a website still demands excessive fields, records everything it receives or combines data across contexts. Good cryptography does not make those choices disappear.

The principles direct attention to the request itself, the explanation offered to the person and the continuing use of the information. They also recognize that information convenient for a service operator can create exposure beyond the user's immediate purpose.

OpenID for Verifiable Presentations supplies a request-and-response protocol rather than another credential data model. Its final specification can work with multiple credential formats and defines how a verifier asks a wallet for presentations. A fresh random nonce binds a response to a particular request and session. The treatment of holder binding is explicit: accepting a credential without a cryptographic holder-binding proof carries replay implications.

This distinction prevents a common conceptual shortcut in which possession of a copied credential file is assumed to prove the presenter's authority. A deployment must choose its credential format, request rules and binding requirements together, and verify the resulting exchange rather than simply parse a credential successfully.

The OpenID Foundation announced approval of OpenID for Verifiable Presentations 1.0 as a Final Specification in July 2025 after its membership vote. That process is distinct from W3C Recommendation status. A system can combine a W3C credential model with an OpenID exchange protocol without the two organizations having standardized the same layer. Conversely, support for an exchange protocol does not imply support for every credential format it can carry. Useful compatibility claims name the protocol version, credential profile and security features tested between particular implementations.

The approval record establishes a published milestone and governance outcome; it does not serve as a deployment certificate for every identity wallet.

DID Core 1.1 was published as a Candidate Recommendation Snapshot on March 5, 2026. That status invites implementation experience and testing against exit criteria, including independent implementations of features. It should not be collapsed into the completed status of DID Core 1.0. The publication also points to related resolution work, illustrating how specifying an identifier and standardizing all of its operational interactions are different tasks. For an implementer, a stable reference means recording the document edition actually followed.

For a reader, a claim that something follows the latest DID standard needs enough detail to distinguish a Recommendation from a candidate snapshot or an editor's changing draft.

The DID Working Group's response to formal objections defended standardizing a shared data model and serialization before requiring all underlying DID methods to be standardized together. It argued that compatibility at the core layer was meaningful even when methods used different infrastructures. The response also described the group's charter boundary: method standardization was separate work. This is a substantive architectural disagreement, because developers may mean either readable documents or interchangeable end-to-end systems when they say interoperability.

A resolver, wallet and verifier can share a vocabulary while still requiring method-specific code and governance assumptions. The Working Group's defense explains its intended scope; it should be read alongside the objectors' different expectations.