11. Interoperability

Draft 0.1, chapter added 2026-09-14. Maps the Record and its receipts, field by field, onto the three credential standards receivers already know: the W3C Verifiable Credentials Data Model 2.0, 1EdTech Open Badges 3.0, and 1EdTech Comprehensive Learner Record 2.0. Chapter 07 documents the one credential the reference implementation issues today and sketches these mappings; this chapter checks them against the published specifications and states what a bridge export would emit. No bridge is built; every mapping here is planned until code ships. Status vocabulary per row: maps (a field-for-field correspondence exists and loses nothing), partial (a slot exists but the meaning narrows), none (no counterpart; the bridge carries it in prose or drops it). Facts about the external specifications were checked against their published text and schemas on 2026-09-14; a statement that could not be checked is marked "verify:" rather than asserted.

11.1 The three standards, and what each one is for

W3C Verifiable Credentials Data Model 2.0 (W3C Recommendation, 15 May 2025) is the envelope. A credential is a JSON-LD document whose @context array MUST begin with https://www.w3.org/ns/credentials/v2, whose type includes VerifiableCredential, whose issuer is a URL or an object carrying id (and optionally name and description), whose validity is validFrom and validUntil (the 1.1 names issuanceDate and expirationDate are gone), and whose credentialSubject MAY carry an id and MAY not. Optional top-level name and description are strings or language objects. credentialStatus, credentialSchema, and termsOfUse are typed objects; evidence is a typed object or array; relatedResource (section 5.3 there) ties a credential to bytes elsewhere: each object MUST carry an id and at least one of digestSRI or digestMultibase, with an optional mediaType, so the mechanism is for a resource whose bytes are stable at its URL and can be digested. Securing is delegated: an embedded proof follows the separate Data Integrity specifications, or the whole credential is enveloped with JOSE or COSE and referenced as an EnvelopedVerifiableCredential.

Data Integrity EdDSA Cryptosuites 1.0 (W3C Recommendation, 15 May 2025) defines the two suites an embedded EdDSA proof can name. eddsa-jcs-2022 canonicalizes with JCS (RFC 8785), which is the dialect chapter 02 uses on the values the Record signs; eddsa-rdfc-2022 canonicalizes the RDF dataset and needs a JSON-LD processor. For eddsa-jcs-2022 the published algorithm is: at creation, copy the document's @context onto the proof; hash the canonical proof configuration and the canonical document separately with SHA-256; join proofConfigHash first and transformedDocumentHash second; sign the 64 bytes with Ed25519; render proofValue as base58-btc multibase with the z prefix. At verification, when the proof carries @context, the document's @context MUST start with the proof's values in the same order. The reference implementation's credential proof (chapter 07, vector v20) uses this order and copies @context onto the proof (shared/verifiableCredentials.js); its verifiers (api/verify-credential.js, verifyCredentialProof in the published verifier) do not perform the @context prefix check, which is a leniency on the verifying side only: a credential the reference implementation issues satisfies the check, and a conforming external verifier will accept it. Section 11.6 records this.

Open Badges 3.0 (1EdTech; specification version 3.0, document version 1.4.5 as published, aligned to the VC Data Model 2.0) is the unit-of-achievement profile. An AchievementCredential is a VC whose @context adds https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json, whose type includes VerifiableCredential and either AchievementCredential or OpenBadgeCredential, and which requires @context, id, type, credentialSubject, issuer, and validFrom. It adds awardedDate, name, description, image, evidence, endorsement, endorsementJwt, credentialStatus, credentialSchema, refreshService, and termsOfUse. Its subject is an AchievementSubject (required: type, achievement; optional: id, identifier, result, source, narrative, term, creditsEarned, activityStartDate, activityEndDate, role, licenseNumber, image) holding one Achievement (required: id, type, name, description, criteria; optional: achievementType from an enumeration that includes Course, Competency, LearningProgram, CommunityService, CoCurricular, Fieldwork, Assignment, Assessment, and others; creditsAvailable, alignment, resultDescription, creator, tag, humanCode, fieldOfStudy). A Result carries value, achievedLevel, status, alignment, and a resultDescription reference whose ResultDescription names a resultType (LetterGrade, GradePointAverage, Percent, PerformanceLevel, RawScore, Result, Status, and others). Evidence requires only type and offers id, name, narrative, description, genre, audience. A Profile (issuer or source) carries id, type, name, url, email, phone, description, image, address, otherIdentifier, official, and the person terms givenName, familyName, additionalName, patronymicName, honorificPrefix, honorificSuffix, familyNamePrefix, and dateOfBirth, plus parentOrg (itself a Profile), all sit on Profile in the published schema, so a person can be an issuer. An IdentityObject names a subject without a DID: identityType (an enumeration including name, emailAddress, identifier), identityHash, hashed, salt. An EndorsementCredential (type includes VerifiableCredential and EndorsementCredential; required @context, id, type, name, credentialSubject, issuer, validFrom) lets a third party vouch: its EndorsementSubject is the id of the thing endorsed plus an optional endorsementComment. Proofs: the specification names a JWT proof format and a linked-data proof format (verify: which Data Integrity cryptosuites it enumerates for the latter; eddsa-rdfc-2022 is the common choice in that ecosystem, and eddsa-jcs-2022 may not be listed).

Comprehensive Learner Record 2.0 (1EdTech; specification version 2.0, document version 1.1, issued 14 October 2025) is the container. A ClrCredential is a VC whose @context adds https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json, whose type includes VerifiableCredential and ClrCredential, and which requires @context, id, type, name, credentialSubject, issuer, and validFrom; it adds description, awardedDate, validUntil, image, partial, evidence, endorsement, endorsementJwt, credentialStatus, credentialSchema, refreshService, termsOfUse. Its subject is a ClrSubject (required: type, verifiableCredential; optional: id, identifier, achievement, association). verifiableCredential holds the embedded credentials (the specification's prose names AchievementCredential and EndorsementCredential; verify: whether a compact JWS string is accepted in that array alongside objects). An Association relates two embedded credentials: associationType from exactMatchOf, isChildOf, isParentOf, isPartOf, isPeerOf, isRelatedTo, precedes, replacedBy, with sourceId and targetId. The issuer is a Profile or a URI, and each embedded credential keeps its own issuer, so a container issued by one party may hold credentials issued by others. Correction to chapter 07, section 7.4: the published ClrCredential schema does not place narrative, activityStartDate, activityEndDate, image, or source on ClrSubject; those live on AchievementSubject. The two rows in chapter 07 that map program, philosophy, and the year range onto ClrSubject are withdrawn by this chapter (section 11.3.1 says where they go instead).

11.2 Identity: who the issuer is, and who the learner is

11.3 Mapping tables

The source columns name the fields of the public verify payloads of chapter 06, section 6.3, because those are exactly the facts the family already made public; a bridge MUST NOT export more than that without the family's explicit choice at export time (chapter 07, section 7.5, rule 2).

11.3.1 The Witness Transcript™ (tr_) as a ClrCredential

11.3.2 A course row (cr_) as an AchievementCredential

11.3.3 A witness attestation (att_)

Two shapes are possible. Which one is honest depends on who holds a key.

Rule for the second shape: an EndorsementCredential MUST be secured by the endorser's own key. No witness holds a key today, so a bridge MUST NOT emit endorsement credentials with a witness as issuer signed by anyone else; doing so would state, in a machine-readable field, a signature the witness never made. The Evidence shape is the honest export until then.

11.3.4 An issuer declaration (a cr_ with declared_by: "issuer")

The declaration is an ordinary course row (chapter 02, section 2.4: same hash domain, same id, same signatures), so section 11.3.2 applies with these differences:

11.3.5 Work samples, notes, walls, and the key binding

11.4 What a bridge export would emit

Planned. The reference implementation issues none of this today; chapter 07, section 7.1 is what exists. The shape below is fixed by this chapter so a standards reviewer can mark it against a text, and so the bridge, when it ships, has a contract to be tested against.

For one course row with one co-signature:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "id": "https://eformogi.com/verify/cr_0ad5487e3ca4",
  "type": ["VerifiableCredential", "AchievementCredential"],
  "name": "Algebra II",
  "description": "Algebra II, 2025-26 Year, recorded by Chen Family Records Office. Receipt cr_0ad5487e3ca4, sha256 0ad5487e3ca41a0994f917602b49e7ecf08e925077395605f3d7f33b1594eb10.",
  "issuer": { "id": "did:key:z6Mk...", "type": "Profile", "name": "Chen Family Records Office" },
  "validFrom": "2026-05-12T14:08:00.000Z",
  "awardedDate": "2026-05-12T14:08:00.000Z",
  "credentialSubject": {
    "type": "AchievementSubject",
    "identifier": [{ "type": "IdentityObject", "identityType": "name", "hashed": false, "identityHash": "Maya Chen" }],
    "term": "2025-26 Year",
    "creditsEarned": 1,
    "result": [{ "type": "Result", "value": "A", "resultDescription": "https://eformogi.com/verify/cr_0ad5487e3ca4#stated-grade" }],
    "achievement": {
      "id": "https://eformogi.com/verify/cr_0ad5487e3ca4#achievement",
      "type": "Achievement",
      "name": "Algebra II",
      "description": "Algebra II, 2025-26 Year, Chen Family Records Office.",
      "achievementType": "Course",
      "creditsAvailable": 1,
      "criteria": { "narrative": "Recorded on a family-issued transcript. The grade is the issuer's statement. Co-signatures, if any, are listed as evidence." },
      "resultDescription": [{ "id": "https://eformogi.com/verify/cr_0ad5487e3ca4#stated-grade", "type": "ResultDescription", "name": "Grade as stated by the issuer", "resultType": "LetterGrade" }]
    }
  },
  "evidence": [{
    "type": "Evidence",
    "id": "https://eformogi.com/verify/att_5d9b296a66cb",
    "name": "Sarah Kim, Tutor",
    "description": "Co-signed the grade A on 2026-06-01. Identity level 1 (invited at a school address). Statement: weekly sessions across the year.",
    "genre": "witness attestation",
    "audience": "Lincoln High"
  }],
  "termsOfUse": [{
    "type": "EformogiRecordTerms",
    "verify": "https://eformogi.com/verify/cr_0ad5487e3ca4",
    "proof": "https://eformogi.com/api/receipt-proof?id=cr_0ad5487e3ca4",
    "key_binding": "https://eformogi.com/verify/kb_b5ed898815ac",
    "custody": "The signing key is held in escrow by Eformogi, Inc. on the family's behalf (chapter 04, section 4.7).",
    "revocation": "Withdrawal is visible only at the verify URL; no status list is served.",
    "meaning": "The hash proves the bytes have not changed since issuance. It does not prove the claim was evaluated by a third party."
  }],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-09-14T00:00:00Z",
    "verificationMethod": "did:key:z6Mk...#z6Mk...",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

Points a reviewer should notice: the id values are the verify URLs (partial, section 11.3.1); there is no relatedResource, because VC 2.0 requires a digest of the bytes at each entry's id and none of the verify page, the proof, or the key-binding page has stable bytes, so the three URLs ride in termsOfUse and the receipt's sha256 in description; creditsEarned is a numeric projection of a string the receipt hashes verbatim; the evidence description carries in words three facts no slot exists for (the co-signed grade, the identity level, the statement); termsOfUse uses a type of the Record's own (verify: whether an unregistered termsOfUse type is acceptable to the OB 3.0 validator, which may require a term the context defines); the proof names the family key as verificationMethod, and the did:key method lets any verifier derive the public key from the identifier itself, so no DID resolution over the network is needed.

The transcript wrapper is the ClrCredential of section 11.3.1: name, issuer, validFrom, awardedDate, a ClrSubject with the IdentityObject, one embedded AchievementCredential per row exactly as above, and one isPartOf association per row. Nothing in the wrapper restates a row; the rows are the credentials.

11.5 Rules for the bridge (MUST), extending chapter 07, section 7.5

1. Every exported credential MUST link the receipt it was derived from: id is the receipt's verify URL, description carries the receipt id and its sha256, and termsOfUse names the proof URL, so a receiver can drop back to chapter 06 and verify the source independently of the export's own proof. relatedResource MUST NOT be used for any of these, because VC 2.0 section 5.3 requires each entry to carry a digest of the bytes at its id and none of them has stable bytes; it MAY be used only for a resource that does (none exists today).
2. An export MUST NOT contain more than the public verify payload does, unless the family includes more at export time. Names, dates, and grades the family printed are in; philosophy, evidence bytes, note bodies, and every account or vault identifier are out.
3. The escrow fact, the revocation gap, and the honesty statement of chapter 06, section 6.6 MUST travel in termsOfUse or description, in words a person can read.
4. A self-declared witness, an issuer-declared tier, and a witness's own grade MUST NOT become a Result, an EndorsementCredential, or any field a receiver could read as third-party evaluation. Chapter 07, section 7.5, rule 4, restated because these are the fields the standards make it easiest to overstate.
5. EndorsementCredential MUST be signed by the endorser's own key or not emitted. The operator's ceremony countersignature MAY be emitted as an endorsement by did:web:eformogi.com only with the comment that says it endorses processing, not the claim.
6. Numbers in signed documents MUST be JCS-safe; credits is coerced by jcsCoerceNumbers before signing (chapter 07), and the string form the receipt hashed MUST also appear (in description) so the two can be reconciled.
7. The name Witness Transcript MUST appear in an export only under chapter 10, section 10.8.
8. An export MUST validate against the published OB 3.0 and CLR 2.0 JSON schemas before it ships, and the schema versions it validated against MUST be recorded in credentialSchema (type per the 1EdTech schema validator; verify: the exact type string the current schemas expect).

11.6 Known divergences and open checks

11.7 What this does not prove

A mapping proves that a field can be carried; it does not prove that a receiver's software will read it the way the Record means it. The three standards have no slot for the facts the Record is most careful about: who checked a signer's identity and how far, whether a witness disagreed with the family's grade, which tier the family itself claimed for a row, and whether a key was held by the family or in escrow. Every one of those facts survives only as prose in the export, and every export MUST keep the verify URL as the place a receiver goes to read them in the shape they were made. Nothing in this chapter is a claim that any receiver accepts a Witness Transcript, a ClrCredential built from one, or anything else.