9. Proof of compatibility¶

9.1 Purpose¶

The Proof of Compatibility is a machine-verifiable credential attesting the successful outcome of a technical compatibility assessment. Where an assessed artefact — a verifiable credential, verifiable presentation or extension — satisfies all applicable compatibility criteria, a Proof of Compatibility is issued as cap:Certification, expressed using the Conformity Assessment Profile (CAP) ontology and carried in a VC-JWT signed by the conformity assessment body accredited for this type of assessment.

Expressing this (positive) assessment result as a credential allows it to:

• be verified using the same mechanisms as other Gaia-X Credentials;
• be presented, stored and exchanged using standard credential mechanisms;
• be referenced by a Meta-Registry trust profile record as evidence of the common technical compatibility layer required by EXT-5.1

The Proof of Compatibility attests technical compatibility only. It does not attest compliance with the rules of any ecosystem and is not a compliance credential.

9.2 Conformity assessment schemes¶

A Proof of Compatibility is issued against a declared conformity assessment scheme, carried in cap:conformity_assessment_scheme as a cap:ConformityAssessmentScheme with a cap:name and a cap:version.

Three conformity assessment schemes are defined:

The cap:version identifies the version of the criteria set against which the assessment was performed, so that a verifier can determine which version of this specification the certification was issued against.

9.3 Structure of the proof¶

The Proof of Compatibility is a Verifiable Credential typed cap:Certification in which:

• the issuer is the did:web identifier of the body that performed the assessment;
• the credentialSubject is typed cap:Certification and carries:
  • cap:object — the assessed artefact, by id and type;
  • cap:conformity_assessment_scheme — the scheme name and version, per the table above;
  • cap:issuance_datetime, cap:valid_from_datetime, cap:valid_until_datetime — the assessment and validity timestamps;
  • cap:issuer — the Conformity Assessment Body that performed the assessment, typed both cap:ConformityAssessmentBody and gx:LegalPerson;
• the evidence array carries one cap:Evidence entry per assessed artefact, binding the certification to the exact bytes assessed through a digestSRI hash.

The per-criterion outcome is not carried in the credential. A Proof of Compatibility is issued only where all applicable criteria defined by the scheme are satisfied; the criterion-level detail belongs to the reports described under Reporting. The digestSRI in evidence is what ties the certification to the specific artefact that was assessed — a modified artefact no longer matches the digest.

The following example is non-normative and shows the decoded payload of the VC-JWT for a credential assessed under the Verifiable Credential Compatibility scheme.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://eclipse-dataspace-cap.github.io/cap-ontology/cap.jsonld",
    "https://w3id.org/gaia-x/development#",
    {
      "vcard": "http://www.w3.org/2006/vcard/ns#"
    }
  ],
  "type": [
    "VerifiableCredential",
    "cap:Certification"
  ],
  "id": "https://example.org/.well-known/compatibility-credential.jwt",
  "issuer": "did:web:tck.example.org",
  "validFrom": "2026-08-27T06:24:26.801Z",
  "validUntil": "2026-11-25T06:24:26.801Z",
  "credentialSubject": {
    "id": "https://example.org/.well-known/compatibility-credential.jwt#cs",
    "@type": "cap:Certification",
    "cap:object": {
      "id": "https://example.org/.well-known/legal-person.json",
      "type": [
        "VerifiableCredential",
        "gx:LegalPerson"
      ]
    },
    "cap:conformity_assessment_scheme": {
      "@type": "cap:ConformityAssessmentScheme",
      "cap:name": "Gaia-X Verifiable Credential Compatibility",
      "cap:version": "1.0.0"
    },
    "cap:issuance_datetime": "2026-08-27T06:24:26.801Z",
    "cap:valid_from_datetime": "2026-08-27T06:24:26.801Z",
    "cap:valid_until_datetime": "2026-11-25T06:24:26.801Z",
    "cap:issuer": {
      "id": "did:web:tck.example.org",
      "type": [
        "cap:ConformityAssessmentBody",
        "gx:LegalPerson"
      ],
      "gx:legalName": "Example Conformity Assessment Body",
      "gx:legalAddress": {
        "type": "gx:Address",
        "gx:countryCode": "BE",
        "vcard:street-address": "1 Example Street",
        "vcard:locality": "Brussels",
        "vcard:postal-code": "1000"
      },
      "gx:headquartersAddress": {
        "type": "gx:Address",
        "gx:countryCode": "BE",
        "vcard:street-address": "1 Example Street",
        "vcard:locality": "Brussels",
        "vcard:postal-code": "1000"
      },
      "gx:registrationNumber": {
        "id": "https://example.org/.well-known/vatID.json#cs"
      }
    }
  },
  "evidence": [
    {
      "id": "https://example.org/.well-known/legal-person.json",
      "type": "cap:Evidence",
      "digestSRI": "sha256-5a0208274b9b700fed9bd27e887adab3810e0fb40c664d17a3549c82405bd9ae"
    }
  ]
}

For the Verifiable Presentation and Extension schemes the structure is identical; only cap:name, cap:object and the evidence entries differ. An extension certification names the Meta-Registry trust profile record applicable to the extension as cap:object; a presentation certification names the assessed Verifiable Presentation.

9.4 Self-application¶

Because the Proof of Compatibility is itself a Verifiable Credential, it shall satisfy all applicable criteria of the Verifiable Credential compatibility chapter. This allows it to be verified using the same mechanisms as other compatible credentials.

9.5 Reporting¶

Alongside the Proof of Compatibility credential, an assessment produces:

• a human-readable report, listing each criterion, its verification method, and its result;
• a machine-readable report, suitable for automated processing in a build pipeline or a compliance workflow.

This specification does not prescribe the form or format of these reports.

Where an artefact fails one or more applicable criteria, no Proof of Compatibility may be issued. The corresponding report is still produced and identifies each failing criterion by the identifier presecribed in section 2.6. The report may also give more specific information supporting the submitter of the artefact in identifying causes for the failure of the conformance testing.