We maintain a DID consumer library (@peac/adapter-did, part of PEAC Protocol) that resolves DID Documents as inputs to signature verification for signed interaction records. The library was released on April 1, 2026, supports did:key and did:web, and is used to verify issuer identity in signed records carried across MCP, A2A, x402, and gRPC transports.
This is feedback from the perspective of a consumer implementation, not a DID method author. Our use is narrow and verifier-oriented: we consume DID Documents to make trust and verification decisions for signed records. That use case surfaces a different class of interoperability questions than broader identity or wallet applications.
We are aware of the recent agent-related issues in this repo (#926, #927, #928, and #929). Our feedback is complementary but distinct. We are not asking DID Core to add agent-specific features. We are reporting practical consumer-side implementation issues encountered while building a verifier.
The initial CR review period ended April 5, but the specification remains in active Candidate Recommendation. We are filing this as implementation experience during the active CR phase.
1. Section 6.3.1 is useful and should be preserved
The non-normative guidance in Section 6.3.1 on lower-precision media types is useful in practice.
For did:web consumers, real endpoints still sometimes serve application/json or application/ld+json even when the payload is clearly intended to be a DID Document. The current guidance is valuable because it gives implementers a path to be precise without being brittle: validate the payload, not just the header.
We would encourage the working group to preserve this direction in the final Recommendation. A short non-normative note clarifying whether consumers should treat lower-precision types as tolerated interoperability behavior, rather than the preferred long-term norm, would help implementers converge.
2. Multi-key DID Documents need a clearer consumer-side disambiguation story
A recurring implementation problem is key selection when a DID Document contains multiple eligible verification methods of the same cryptographic family and the consumer needs exactly one verification key.
Our current behavior is conservative:
- if a specific key identifier is supplied, require an exact match
- otherwise narrow using the relevant verification relationship
- if multiple eligible keys still remain, fail rather than guess
That has worked well from a security perspective, but it is an area where consumer behavior can diverge even when all implementations believe they are being reasonable.
A short non-normative recommendation would help. For example: when more than one eligible verification method remains after applying the relevant relationship, consumers should require explicit disambiguation rather than selecting arbitrarily.
3. Historical verification and deactivation need clearer temporal framing
Our primary use case is verifying signed records that may reference DIDs which were valid at issuance time but have since been deactivated. This creates a practical question: should didDocumentMetadata.deactivated === true prevent verification of a record that was created and signed before deactivation?
For systems that verify durable records, the distinction between prospective-only deactivation and retroactive invalidation matters significantly. Our current approach is to accept the record but surface deactivation as a warning rather than a hard failure.
Clearer framing of the intended interpretation would help implementers avoid incompatible assumptions. This may belong in DID Resolution rather than DID Core, but it is a real interop issue for verifiers.
4. Caching and freshness guidance would reduce consumer implementation drift
With DID Resolution separated into its own specification, caching and freshness policy is where consumer implementations will diverge next.
The questions arise quickly:
- how long a successful resolution result should be cached
- whether failed resolutions should be cached at all
- how key rotation expectations should affect freshness policy
- how consumers should balance stale-data risk against availability
Our implementation uses short-lived success-only caching, no negative caching, deep-copy isolation, and oldest-first eviction. Those are reasonable defaults, but there is no shared guidance that helps implementations converge.
Given that DID Resolution remains an active work item, this feels like the right place for non-normative guidance or shared test cases on freshness expectations.
5. did:web consumers need a more visible security baseline
Several did:web hardening measures are individually well-known but easy to miss in aggregate. From our implementation, a minimum consumer-side baseline includes:
- rejecting IP-literal targets
- rejecting redirects during resolution
- validating that the resolved document
id exactly matches the requested DID
- applying size limits and timeouts to the fetch
- using domain allowlists where the deployment model permits it
These are not novel, but they represent a practical security floor for new consumers. Stronger visibility in security guidance, even as a non-normative checklist, would help raise the baseline.
6. The consumer-verifier use case is worth keeping visible
Much of DID discussion naturally centers on identity issuance, portability, and control by the DID subject. Those are important. But there is also a growing class of verifier-oriented implementations that use DIDs as a trust input for signed machine actions, service assertions, and cross-system evidence.
That use case cares about:
- deterministic key selection
- temporal interpretation of deactivation
- resolver safety
- reproducible verification outcomes
These overlap with, but are not identical to, the concerns of identity-issuance implementations.
Keeping the consumer-verifier perspective visible during final editorial review and implementation report analysis would be helpful.
Summary
From a DID consumer verifier used for signed interaction records, the areas where additional clarity would help most are:
- preserve Section 6.3.1's pragmatic guidance on lower-precision media types
- add non-normative guidance for multi-key disambiguation by consumers
- clarify temporal semantics of deactivation for historical verification
- include caching and freshness guidance in DID Resolution
- raise the visibility of
did:web consumer security baselines
Our implementation is open source at https://github.com/peacprotocol/peac (@peac/adapter-did). We would be glad to contribute test vectors, implementation notes, or implementation-report input if that would be useful.
Jithin Raj
PEAC Protocol
https://github.com/peacprotocol/peac
We maintain a DID consumer library (
@peac/adapter-did, part of PEAC Protocol) that resolves DID Documents as inputs to signature verification for signed interaction records. The library was released on April 1, 2026, supportsdid:keyanddid:web, and is used to verify issuer identity in signed records carried across MCP, A2A, x402, and gRPC transports.This is feedback from the perspective of a consumer implementation, not a DID method author. Our use is narrow and verifier-oriented: we consume DID Documents to make trust and verification decisions for signed records. That use case surfaces a different class of interoperability questions than broader identity or wallet applications.
We are aware of the recent agent-related issues in this repo (#926, #927, #928, and #929). Our feedback is complementary but distinct. We are not asking DID Core to add agent-specific features. We are reporting practical consumer-side implementation issues encountered while building a verifier.
The initial CR review period ended April 5, but the specification remains in active Candidate Recommendation. We are filing this as implementation experience during the active CR phase.
1. Section 6.3.1 is useful and should be preserved
The non-normative guidance in Section 6.3.1 on lower-precision media types is useful in practice.
For
did:webconsumers, real endpoints still sometimes serveapplication/jsonorapplication/ld+jsoneven when the payload is clearly intended to be a DID Document. The current guidance is valuable because it gives implementers a path to be precise without being brittle: validate the payload, not just the header.We would encourage the working group to preserve this direction in the final Recommendation. A short non-normative note clarifying whether consumers should treat lower-precision types as tolerated interoperability behavior, rather than the preferred long-term norm, would help implementers converge.
2. Multi-key DID Documents need a clearer consumer-side disambiguation story
A recurring implementation problem is key selection when a DID Document contains multiple eligible verification methods of the same cryptographic family and the consumer needs exactly one verification key.
Our current behavior is conservative:
That has worked well from a security perspective, but it is an area where consumer behavior can diverge even when all implementations believe they are being reasonable.
A short non-normative recommendation would help. For example: when more than one eligible verification method remains after applying the relevant relationship, consumers should require explicit disambiguation rather than selecting arbitrarily.
3. Historical verification and deactivation need clearer temporal framing
Our primary use case is verifying signed records that may reference DIDs which were valid at issuance time but have since been deactivated. This creates a practical question: should
didDocumentMetadata.deactivated === trueprevent verification of a record that was created and signed before deactivation?For systems that verify durable records, the distinction between prospective-only deactivation and retroactive invalidation matters significantly. Our current approach is to accept the record but surface deactivation as a warning rather than a hard failure.
Clearer framing of the intended interpretation would help implementers avoid incompatible assumptions. This may belong in DID Resolution rather than DID Core, but it is a real interop issue for verifiers.
4. Caching and freshness guidance would reduce consumer implementation drift
With DID Resolution separated into its own specification, caching and freshness policy is where consumer implementations will diverge next.
The questions arise quickly:
Our implementation uses short-lived success-only caching, no negative caching, deep-copy isolation, and oldest-first eviction. Those are reasonable defaults, but there is no shared guidance that helps implementations converge.
Given that DID Resolution remains an active work item, this feels like the right place for non-normative guidance or shared test cases on freshness expectations.
5.
did:webconsumers need a more visible security baselineSeveral
did:webhardening measures are individually well-known but easy to miss in aggregate. From our implementation, a minimum consumer-side baseline includes:idexactly matches the requested DIDThese are not novel, but they represent a practical security floor for new consumers. Stronger visibility in security guidance, even as a non-normative checklist, would help raise the baseline.
6. The consumer-verifier use case is worth keeping visible
Much of DID discussion naturally centers on identity issuance, portability, and control by the DID subject. Those are important. But there is also a growing class of verifier-oriented implementations that use DIDs as a trust input for signed machine actions, service assertions, and cross-system evidence.
That use case cares about:
These overlap with, but are not identical to, the concerns of identity-issuance implementations.
Keeping the consumer-verifier perspective visible during final editorial review and implementation report analysis would be helpful.
Summary
From a DID consumer verifier used for signed interaction records, the areas where additional clarity would help most are:
did:webconsumer security baselinesOur implementation is open source at https://github.com/peacprotocol/peac (
@peac/adapter-did). We would be glad to contribute test vectors, implementation notes, or implementation-report input if that would be useful.Jithin Raj
PEAC Protocol
https://github.com/peacprotocol/peac