Problem Statement

The current implementation of the Agent Badge as a Verifiable Credential (VC) in the AGNTCY Identity Service
generally follows the structure of the W3C Verifiable Credentials Data Model 2.0 (VCDM 2.0)
.
However, several aspects are not yet fully aligned with the normative requirements and interoperability expectations of VCDM 2.0.

Key alignment gaps include:

• The issuer property may not strictly follow the VCDM 2.0 rule (must be a URL or an object with an id as URL...or eventually DID...but it should be an URI as RFC 3986).
• The @context does not explicitly include AGNTCY-specific extensions which are not documented but needed to respect the semantic of the JSON-LD rules specifications.
• There is currently no revocation or credential status mechanism.
• The securing mechanism is not clearly defined (e.g., embedded proof vs. external signing, both ?).
• No formal AGNTCY VC Profile is declared, limiting interoperability with standard VC verification libraries and wallets.

It would also be valuable to consider how third-party attestations or certifications (issued by other entities) could be added to an agent’s portfolio (called now identity./data wallet). This would enable richer trust models and cross-ecosystem identity representations. However, such capability requires strict conformance with the VC format and data model, to ensure that credentials issued by other systems can be recognized, verified, and stored consistently.

Without these clarifications, third-party verifiers and external systems cannot reliably validate AGNTCY Agent Badges and these Badges remain for internal use only.

Proposed Solution

Define an AGNTCY VC Profile aligned with VCDM 2.0, specifying:

• Required and optional properties (@context, type, issuer, credentialSubject, proof, etc.)

• Identifier formats (URL, DID, URN).

• Supported proof suites (DataIntegrityProof, JsonWebSignature2020, etc.).

• Expected proofPurpose values and verification methods.

• Clarify the Securing Mechanism: explicitly choose between:
  -Embedded proofs (included directly in the credential, e.g. DataIntegrityProof) see https://www.w3.org/TR/vc-data-integrity/ or
  -External securing mechanisms (e.g., COSE/JWS signatures or external proof services), see https://www.w3.org/TR/vc-jose-cose/

• Integrate the concept of Verifiable Presentation which is absolutly needed for the verification step.

• Implement a Revocation / Status System as Bitstring Status List 2.0
  for scalable and privacy-preserving revocation.

• Add validation and tests (or refer to community test suite) ensuring every issued credential adheres to the AGNTCY VC Profile and publish example credentials to help integrators validate compliance.

Alternatives Considered

Do not adhere to VCDM 2.0 — instead, adopt the simpler IETF SD-JWT VC approach.
This alternative may reduce complexity and leverage existing JWT tooling, at the cost of losing JSON-LD interoperability and linked-data extensibility.

Additional Context

W3C Verifiable Credentials Data Model 2.0

W3C Bitstring Status List 2.0

IETF SD-JWT VC Draft

Checklist

• I have read the contributing guidelines
• I have verified this does not duplicate an existing feature request