How should scheme operators govern OpenID for Verifiable Credentials implementations?

Why This Matters for Security Teams

OpenID for Verifiable Credentials is not just another identity protocol to register and forget. For scheme operators, the governance problem is deciding who can participate, which behaviours are acceptable, and how trust changes over time without breaking interoperability. That means the control plane must cover technical conformance, metadata governance, and assurance renewal together, not as separate workstreams.

Practitioners often underestimate how quickly a seemingly compliant wallet or verifier can drift from the scheme’s intent once policies, cryptographic requirements, or assurance levels change. The result is inconsistent user experience, weakened trust, and avoidable exposure if participants keep operating on stale assumptions. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point to continuous governance, not one-time approval.

NHI Management Group has also observed a broader maturity gap in related identity operations: only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report by Aembit. In practice, many security teams encounter implementation drift only after a verifier rejects credentials or a relying party interprets policy differently, rather than through intentional assurance review.

How It Works in Practice

A workable scheme model starts with a trust registry that defines who is allowed to issue, hold, verify, and rely on credentials. The registry should not only list participants; it should also express onboarding criteria, cryptographic requirements, conformance status, and any assurance profile that applies. That makes governance operational instead of purely contractual.

Scheme operators should separate three decisions:

• Technical conformance: does the wallet, issuer, or verifier implement the protocol correctly?
• Participation eligibility: is the organisation allowed to join the scheme under current trust rules?
• Ongoing assurance: does the implementation still meet policy after updates, key changes, or cryptographic deprecation?

This is where independent testing matters. Self-attestation is useful as an intake step, but it is rarely enough for interoperability at scale. Current best practice is to require external validation against the scheme profile, then revalidate when policy changes, assurance levels increase, or significant product changes occur. The same logic appears in identity guidance from NIST SP 800-63 Digital Identity Guidelines, which treats identity assurance as something that must be maintained, not merely declared.

Operators should also define how metadata is governed. That includes approved algorithms, issuance endpoints, revocation status handling, and the versioning rules that relying parties use to determine trust. If metadata is ambiguous, participants will fill the gap with local assumptions, and those assumptions will diverge. The practical lesson is reinforced by NHIMG research on the Guide to the Secret Sprawl Challenge and the Top 10 NHI Issues, both of which show how unmanaged trust inputs create control-plane sprawl.

Governance should also include incident response for trust changes, such as suspension, revocation, and emergency policy updates. These controls tend to break down when a scheme spans multiple jurisdictions and legacy wallets because policy synchronisation and version enforcement become inconsistent across participants.

Common Variations and Edge Cases

Tighter conformance testing often increases onboarding cost and slows ecosystem growth, requiring operators to balance trust strength against participant friction. That tradeoff is real, especially in schemes that need broad adoption or support for older wallets.

One common edge case is partial interoperability. A wallet may pass the core protocol checks yet fail on optional features, credential formats, or presentation flows. Current guidance suggests operators should clearly label support tiers rather than treat partial compatibility as full approval. Another edge case is delegated trust, where a parent organisation onboards subsidiaries or regional issuers. Without explicit trust registry rules, responsibility for key management, revocation, and change control becomes unclear.

Another practical exception is policy evolution. If assurance levels or cryptographic baselines change, operators should revalidate implementations even when the software version has not changed. Otherwise, a technically functioning participant may still be out of scheme policy. This is especially important when relying parties cache metadata or when governance depends on external status services.

NHIMG analysis of breach and secret-sprawl patterns shows that trust failures are often operational, not theoretical, as seen in the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. For scheme operators, the lesson is simple: governance must remain live, because trust rarely fails at the protocol spec first.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?