ANP 1.2 is now officially released.

This release focuses on three questions: how different DID systems can join the same agent network (starting with native did:web), how identity continuity stays verifiable after key rotation, and how one agent can communicate securely across multiple devices.

ANP 1.2 Is Officially Released: Opening the Agent Network to More DID Methods

Source: https://x.com/changgaowei/article/2103033671171113321 ANP 1.2 is now officially released.

This release focuses on three practical questions: how different DID systems can participate in the same agent network, how identity continuity can be maintained after key rotation, and how a single agent can communicate securely across multiple devices.

Our goal remains unchanged:to enable all agents to connect and collaborate with one another.

To make that possible, ANP needs a common set of communication protocols, while still allowing different participants to choose different identity systems.

1. From did:wba to an Open DID Ecosystem

ANP should not support only the did:wba method developed within our own ecosystem.

Our direction is to support different DID methods that are compatible with the W3C DID architecture, so that agents using different identity systems can all participate in the ANP network.

For this reason, ANP 1.2 separates common DID-based authentication intoANP-02.

The key idea is to separate two concerns:

• each DID method defines how its DID Document and identity material are resolved and verified;
• ANP defines a common request-signing and authentication process on top of that verified identity.

This means that supporting a new DID method should not require redesigning the entire upper-layer authentication protocol.

The first additional DID method supported in ANP 1.2 is nativedid:web.

Next, we plan to supportdid:webvh, as well asBID, the decentralized identity system associated with China’s SparkChain Network.

We also remain open to other DID methods compatible with the W3C DID architecture. If other DID communities or projects are interested in integrating with ANP, we welcome interoperability work and contributions.

Once integrated, an agent can keep its existing DID identity and use ANP on top of it foragent messaging, agent description, and agent discovery.

For example, two companies may use different DID methods. Once both sides support the corresponding ANP identity binding, a procurement agent from one company and a supplier agent from another can discover each other, authenticate each other, and exchange information through the same ANP protocol stack.

They do not need to design a completely separate communication protocol simply because their underlying DID methods are different.

Of course, openness does not mean that every DID method automatically works with ANP. Each method still needs the required resolution, verification, and protocol binding work.

What ANP aims to provide is a common way for different identity systems to join the same open agent network, rather than requiring everyone to adopt a single DID method.

2. Keys Can Change, but Identity Continuity Should Remain Verifiable

For path-based did:wba identities that include a bound public-key fingerprint, rotating the bound key can result in a new full DID.

This provides a useful security property, because the identity is cryptographically bound to the key. But it also introduces a practical question:

How can another party verify that the new DID still represents the same agent?

ANP 1.2 introduces clearer rules for stable subject paths and verifiable DID migration.

The stable subject path cannot be recycled or reassigned, and a verifier must also check the successor relationship and the corresponding cryptographic proof between the old DID and the new DID.

A matching path alone is not enough.

For example, a procurement agent may have worked with the same suppliers for a long time and may periodically rotate its keys.

With the new continuity rules, applications can verify that the new DID belongs to the same continuing subject, and then apply their own business rules for updating memberships, permissions, or other application state.

This reduces the need for every application to invent its own identity-migration mechanism.

It is also important to distinguish identity continuity from authorization.

Verifying that a new DID belongs to the same subject does not automatically mean that every previous permission, encrypted session, or business authorization should be inherited. Those decisions still belong to their respective application or security layers.

3. One Agent, Multiple Secure Devices

An assistant may run on both a laptop and a mobile phone.

From a business perspective, it is still the same agent. But from a cryptographic perspective, the two devices should not simply share the same private session state.

ANP 1.2 therefore separates theagent identityfrom itscryptographic device endpoints.

The DID continues to represent the agent itself, while aDevice Manifestdescribes the currently authorized devices and their corresponding cryptographic keys.

For direct end-to-end encrypted messaging, sessions are established between specific device pairs.

The same logical message can be encrypted separately for each authorized receiving device, rather than relying on multiple devices to share the same private session state.

This makes it possible for personal assistants and enterprise agents deployed across multiple devices or environments to maintain one external identity while managing encrypted communication independently on each device.

The group messaging model follows the same principle: business membership remains DID-based, while cryptographic participation may happen at the device level.

ANP uses MLS as the technical direction for group E2EE. However, the group E2EE profile is still in candidate status and should not yet be treated as a fully stable specification.

4. What Comes Next: Streaming Authentication, Mutual DID Authentication, and Authorization

After ANP 1.2, our next phase will focus on three areas.

First, authentication for streaming communication.

For long-lived streams or data whose complete content is not known before transmission begins, the protocol needs to clarify when identity authentication happens, how content integrity is protected during transmission, and how reconnection should be handled.

Our current direction is to separate authentication at session establishment from integrity protection for the ongoing stream.

Second, mutual DID authentication.

Today, many authentication models focus primarily on proving the identity of the caller.

We want to extend this so that the caller can also verify the DID identity of the responding agent or service.

In other words, both sides should be able to prove who they are, and those proofs should be bound to the actual request and response being exchanged.

Third, combining DID with OAuth for agent authorization.

Authentication answers the question:

“Who are you?”

Authorization answers a different question:

“What are you allowed to do?”

Our goal is not to replace OAuth.

Instead, we want to explore how a stable DID-based agent identity can work together with existing OAuth authorization mechanisms.

For example, the same agent could use one DID identity when connecting to services from different organizations, while each service continues to control what that agent is allowed to access through its own authorization policies and scopes.

These three areas are part of our next stage of work and are not capabilities already completed in ANP 1.2.

ANP 1.2 is a specification release, and support in individual SDKs, services, and products should still be evaluated separately.

From broader identity interoperability, to long-term identity continuity, to authentication and authorization in real communication scenarios, we will continue working on the foundational problems required for an open agent network.

We also welcome DID communities, agent projects, and infrastructure teams to participate in this work and help make cross-platform agent collaboration easier to build.