Web3

DID Reputation Portability: Mapping to W3C VC Data Model

Read how DID verifiable credential interoperability works for escrow-derived work reputation: VC 2.0 fields, DID methods, proof formats, and status lists.

OCT 7, 2026

Share Post Share

TL;DR

A DID-anchored reputation credential is portable only when an outside verifier can resolve its DID method, check its proof, interpret its claims and read its status.
Every VC Data Model 2.0 credential MUST carry four properties: @context, type, issuer and credentialSubject.
Escrow settlement maps naturally to issuance and a dispute ruling to a status change, but that mapping is a design choice, not a disclosed FiduWork schema.
A bitstring status list spends one bit per credential, and its specification sets a 131,072-entry floor, 16 KB uncompressed, for group privacy.
A six-step checklist tests any interoperability claim against the deployed contracts.

DID reputation portability means a verifier that is not the issuing platform can resolve the issuer's DID, verify the proof, interpret the claims and confirm the credential still stands. The W3C VC Data Model 2.0 defines the envelope. It does not pick the DID method, proof format or status channel, and each can break portability.

FiduWork describes its reputation as on-chain, DID-anchored, portable and backed by verifiable credentials; its credential fields, DID method and proof format are not publicly documented. This piece works one layer below that claim: an illustrative mapping of an escrow-derived work credential onto VC 2.0, the EVM options a verifier must handle, and what to check before trusting any portability claim.

What does DID verifiable credential interoperability actually require?

DID verifiable credential interoperability requires a conforming VC document, secured by a mechanism the verifier implements, issued under a DID the verifier can resolve. The working group's editor's source for the data model says a digital credential only counts as compatible with the ecosystem if it is a conforming document and uses at least 1 securing mechanism.

Passing that test is not enough on its own. A verifier-centric model of credential ecosystems observes in its abstract that systems sharing the label digital credential often remain mutually non-interoperable, and that element-by-element comparisons do not explain why interoperability fails even when stacks share a data model. It separates credential processing into three layers: signature verification (L1), semantic interpretation (L2) and validation (L3). A work-reputation credential has to clear all three.

The problem predates 2.0: a 2022 tutorial on self-sovereign identity interoperability noted that differing implementations often create interoperability problems, with no common understanding of SSI interoperability.

Data model, securing mechanism, DID method: three separate compatibility checks

A verifier runs three checks that fail independently. Data model: the document carries the 2.0 context and required properties. Securing mechanism: the verifier implements the proof family the issuer chose. DID method: the verifier resolves the issuer's DID to a DID document, which the W3C DID specification text says contains information such as ways to cryptographically authenticate a DID controller.

Why "DID-anchored" alone does not make a credential readable elsewhere

The companion piece on how wallet-bound credentials get issued and travel covers issuance and portability across clients. Resolving the DID is only the first step toward portability.

A DID tells the verifier where to find keys. It says nothing about which contexts the claims use, which proof family signed them, or where revocation is published. The data model leaves those open: the VC working group's explainer states that the group is not defining protocols or APIs and that the model is identifier agnostic.

How would an escrow-derived reputation record map onto VC Data Model 2.0 (illustrative, not FiduWork's schema)?

Any mapping starts from the 4 properties every credential MUST carry: an @context whose first item is https://www.w3.org/ns/credentials/v2, a type, an issuer and a credentialSubject. The VC data model property rules also define credentialStatus for discovering whether a credential is suspended or revoked, which is where a later dispute outcome would land.

This mapping is illustrative, not FiduWork's deployed schema; verify every field against the deployed issuer contract. The published reputation piece says the exact fields are configured in that contract, so its advice to read the issuer contract first governs everything below.

Required properties and what an escrow event could fill them with (illustrative)

`@context`: the v2 URL first, then any issuer-defined context for work-reputation terms.
`type`: VerifiableCredential plus an issuer-defined type such as a completed-milestone record.
`issuer`: a DID for whoever signs: an operator key, a contract-associated identity or the approving client wallet.
`credentialSubject`: an id holding the freelancer's DID, with claims that could reference the milestone, the settlement asset (USDC) and the outcome.
`validFrom`: settlement time, from the block that released funds.
`credentialStatus`: an entry the issuer can flip if a later ruling changes the record.
`evidence`: the optional evidence property could point at the settlement transaction.

Every row is a design option, not a disclosed FiduWork field name, value or context URL.

Holder and subject: the same wallet, usually

The five-role model in the W3C explainer names issuer, subject, holder, verifier and verifiable data registry, and notes that holder and subject are often the same, though not always. Here the freelancer is the subject and normally the holder.

What a 2.0 credential with a status entry looks like

W3C's own Bitstring Status List explainer shows a 2.0 credential carrying a status entry:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2021-04-05T14:27:42Z",
  "credentialStatus": {
      "id": "https://example.com/credentials/status/3#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://example.com/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  }
}

Copied verbatim from the second code block in Example 1 of the Bitstring Status List explainer, the credential that references the list. It shows shape only, with did:example placeholders; it is neither a work credential nor a FiduWork credential.

How do DID methods anchor issuer and subject keys on an EVM chain?

A DID is a text string in 3 parts: the did URI scheme identifier, the identifier for the DID method, and the method-specific identifier, per the DID specification source in the W3C repository. On an EVM chain the method decides where keys live: in a registry contract the verifier must read, or derived from the account address with no chain read at all.

The DID 1.1 revision's source is at the Candidate Recommendation stage, so DID document and resolution behaviour should be checked against the version a resolver implements.

Protocol mechanics: roles, state transitions, events (illustrative, not FiduWork's deployed schema)

This mapping is illustrative, not FiduWork's deployed schema; verify every field against the deployed issuer contract. The five VC roles map onto an escrow like this:

Issuer: whoever signs: a contract, an operator key or the approving client wallet. Which one signs for FiduWork is not disclosed.
Subject: the freelancer, identified by a wallet-controlled DID.
Holder: normally the same freelancer wallet.
Verifier: a future client, on any platform.
Verifiable data registry: whatever the DID method and status channel read, a chain or a hosted list.

Jurors hold no VC role; they matter only in a dispute, where their ruling is evidence that can change status. The client's milestone approval is the evidence trigger, and the client is also the issuer only if its wallet signs.

On top of the disclosed mechanics (USDC milestone escrow held by a non-custodial contract on Sepolia), a candidate lifecycle runs: funded, milestone approved, USDC released (candidate issuance point). A dispute, if raised, ends in a ruling (candidate status change); where it can enter that sequence is not disclosed. The baseline escrow state list is in the architecture deep dive, which also leaves event names to the deployed contract; the issuer contract's event names are not disclosed either.

A registry-backed DID method emits its own stream. ERC-1056, the lightweight identity registry, status Stagnant and created in 2018, requires DIDOwnerChanged, DIDDelegateChanged and DIDAttributeChanged when an owner, delegate or attribute change succeeds.

Registry-backed versus purely generative methods

The did:ethr method specification builds on the ERC-1056 contract, which it says publishes three types of events for each identifier. It lists Mainnet, Sepolia test-net, Polygon networks and Gnosis chain among its targets and charges no transaction fee for identifier creation. Deactivation sets the owner to 0x0, after which all preexisting keys and services must be considered revoked. ERC-1056's own text explains the zero cost: creating an identity is as simple as creating a regular key pair account, so it is free, with no gas costs.

The did:pkh method draft, still marked Draft, derives a DID directly from a blockchain account, citing hundreds of billions of balance-holding accounts across the major 50 or so blockchains. It is purely generative: no updates are possible, and deactivation is not supported.

The trade-off: a generative DID resolves anywhere with zero chain reads, but its key cannot rotate. A registry DID can rotate and deactivate, but the verifier needs RPC access to the right network and must trust what it reads there.

What a verifier must resolve before checking one signature

Before the first signature check, an outside verifier parses the issuer DID and recognises its method, resolves the DID document by registry read or derivation, and selects the verification method the proof references. It must also decide whether the key had to be valid at validFrom or only now. Registry methods make that a historical chain query; generative methods make it trivial, because nothing rotates.

Which securing mechanism lets a third-party verifier check the proof?

Only the family the verifier implements, because the two W3C families are not designed to be cross-compatible. The Data Integrity explainer lists compatibility with JWTs, JOSE or COSE as a non-goal and points to other specifications in the same working group for that job. A verifier that accepts 2 families runs 2 code paths, and the issuer's choice decides which verifiers can read it at all.

Embedded proofs versus enveloping proofs

The VC 2.0 text describes an embedded proof based on Data Integrity and an enveloping proof based on JOSE/COSE. Data Integrity proofs, per its explainer, can be embedded in their native representation, such as JSON or YAML, instead of being base64-encoded and made opaque to developers and database tooling. The JOSE/COSE explainer notes that multiple methods can secure VC content and details how to use JWTs as a securing mechanism, so the credential becomes the signed payload.

EIP-712 signatures and on-chain attestations are a third family

EVM-native systems can also sign or attest outside both W3C families. EIP-712's typed-data standard, status Final and created in 2017, signs typed structured data under a domain separator built from up to 5 fields: name, version, chainId, verifyingContract and salt. Designers include only the fields that suit their domain. The did:pkh specification draft refers to off-chain signing by externally owned accounts, meaning personal wallets, according to EIP-712.

The EAS contracts repository describes a free and open protocol for on-chain attestations on EVM-compatible blockchains: anyone registers a schema through SchemaRegistry.sol and attests through EAS.sol.

On this piece's reading, neither an EIP-712 signature nor a registry record is by itself a VC 2.0 conforming document; it needs a VC envelope, or a verifier that reads the chain. Which family, if any, FiduWork's credentials use is not disclosed.

Selective disclosure is optional in the data model

The W3C explainer says the data model supports selective disclosure as a best practice but does not require it. A freelancer may want to prove a count of completed milestones without naming clients. A compact selective-disclosure scheme on arXiv reports that its CSD-JWT construction lowers memory use by up to 46% against the state of the art, with presentations 27% to 93% smaller. Those are that scheme's results against its own baseline, not a property of credentials in general.

How should escrow settlement and dispute outcomes reach a portable credential?

Settlement could issue the credential and a later ruling could change its status, with a status list as a space-efficient channel a verifier can check. Per the W3C status-list explainer, a bit set to 1 means the credential is revoked and 0 means it is not, so each credential costs 1 bit of the list before compression.

Escrow contract walkthrough: which state change could issue, which could revoke (illustrative, not FiduWork's deployed schema)

This mapping is illustrative, not FiduWork's deployed schema; verify every field against the deployed issuer contract. The disclosed mechanics are USDC milestone escrow on Sepolia in a non-custodial smart contract. The escrow walkthrough in the wash-rating piece covers the same paths from the anti-gaming angle. Read each path from the position of an outside verifier.

Deposit. The client funds the milestone in USDC. Nothing is delivered, so this mapping issues nothing.
Milestone confirmation. The client approves. Whether release is the same transaction is not disclosed, so this mapping keys issuance to the release, not the approval.
Release. USDC moves to the freelancer: the candidate issuance point, with the settlement transaction as evidence and its block time as validFrom.
Refund. Refund conditions, timers and permitted callers are not disclosed; verify them against the deployed contract. Here a refund issues nothing, so the verifier sees an absence, not a negative mark.
Dispute. The ruling is the candidate revocation point. If issuance can precede a dispute, status must be able to change afterwards; if issuance waits for disputes to close, status is simpler. FiduWork's ordering is not disclosed.

Dispute flow: from a juror ruling to a status bit (illustrative)

Disclosed first: disputes go to an Aragon-OSx panel of 3, 5 or 7 jurors who vote inside the disclosed 72-hour voting window, with a 5% USDC stake from both sides and the stakes split 30% to jurors and 70% to the winner. Odd panel sizes (3, 5 or 7) cannot split evenly on a binary vote when every seated juror votes; how abstentions, missed votes or quorum failure resolve is not disclosed and must be checked against the deployed panel contract. The Aragon-OSx juror panel mechanics piece covers selection and voting.

Propagation from ruling to credential is illustrative. If a ruling overturns an approval that already produced a credential, the issuer can set the credential's status bit, or issue a superseding credential and revoke the old one. Either way, an outside verifier learns of the ruling only if it checks credentialStatus when it verifies. A verifier that cached the credential keeps trusting a record the panel reversed. Whether FiduWork's issuer can change status at all, and how quickly, is not disclosed.

Status lists versus registry events as the revocation channel

A bitstring list is itself a credential at a URL; checking it means fetching the list and reading one index. A registry alternative publishes status as contract state or events, such as attribute changes on an ERC-1056-style registry, and checking it means a chain read. On this piece's arithmetic, 100,000 credentials at one bit each is 100,000 / 8 = 12,500 bytes, the explainer's figure, but the specification's group-privacy minimum requires at least 131,072 entries, 16 KB uncompressed, by default, so a conforming list is not that small unless an ecosystem specification sets a lower bound. The registry needs no separate host but is chain-bound. Neither channel is disclosed for FiduWork.

What breaks when a reputation credential leaves its issuing platform?

It breaks wherever the receiving verifier lacks something the issuer assumed. An arXiv paper presenting an ecosystem-agnostic verifier application says diverse SSI ecosystems pose significant challenges for cross-ecosystem interoperability due to technological and trust framework differences, and its implementation bridges 3 ecosystems: Hyperledger Indy/Aries, EBSI and EUDI. A reputation credential leaving its platform meets the same gap in five failure modes.

Unresolvable DID method

Without a resolver for the issuer's method, a verifier cannot fetch a key. A did:ethr issuer needs verifiers with RPC access to the right network; a did:pkh issuer needs verifiers that support that chain's account format. Choosing a method decides who can verify.

Context and type drift

The specification's rule on JSON-LD contexts says application developers MUST understand every JSON-LD context used by their application, at least as far as it affects the meaning of their terms. Each custom work-reputation context is one more document a verifier must know and trust. A verifier that cannot interpret a term fails at L2 even when L1 passes.

Status checks that leak who is verifying

The status-list privacy notes warn that a one-to-one mapping between a credential and its status URL lets the publisher correlate the holder, time and verifier whenever status is checked, and that a malicious issuer might create a unique status list per credential. An issuer could then learn which prospective clients checked a freelancer's record. Large shared lists dilute that signal.

Signatures replayed out of domain

The EIP-712 specification text states that it does not include replay protection. Its domain can carry a chainId, where the user-agent should refuse signing if it does not match the currently active chain, and a verifyingContract. Both are optional, so a claim signed without them can surface in a context its signer never intended.

Personal data written where it cannot be erased

The did:ethr design notes say a design decision is meant to discourage custom attributes in DID documents, because they would be too easy to misuse for storing personal user information forever on-chain. A credential that writes client names or rates to a chain inherits that problem.

Gaming and collusion are a separate class, analysed in the failure-mode sections of the wash-rating piece.

A verification checklist for interoperability claims

Run these six steps, in order, against any DID verifiable credential interoperability claim:

Resolve the issuer DID with a resolver you control, not one the issuer hosts.
Check the context list: @context starts with https://www.w3.org/ns/credentials/v2, and your verifier understands every context after it.
Match the securing mechanism: Data Integrity, JOSE/COSE, or an EVM-native signature or attestation, and confirm your verifier implements it.
Check status at verification time, from credentialStatus or the registry, not a cached result.
Trace any settlement reference to the escrow contract on Sepolia and confirm the milestone settled.
Read the deployed issuer contract for the actual fields, not any mapping, this one included.

How do on-chain attestations, JOSE-secured and Data Integrity credentials compare?

They differ in where the proof sits and what the verifier must run. A registry protocol like the one in the schema-registry attestation contracts uses 2 core contracts, one to register schemas and one to record attestations, plus optional resolver contracts, so the record lives in chain state. Both W3C families travel with the document instead, and either can carry a credentialStatus entry for revocation.

The table compares the three families on six parameters. None of the columns describes FiduWork's deployed format, which is not disclosed.

Proof placement · Data Integrity-secured VC: Embedded in the JSON document (VC 2.0 text; Data Integrity explainer) · JOSE/COSE-secured VC: Enveloping: the credential is the signed payload (VC 2.0 text; JOSE/COSE explainer) · EIP-712 signed or on-chain registry attestation: Signature over a typed struct, or a record in a registry contract (EIP-712; attestation contracts repository)
W3C VC 2.0 conforming document · Data Integrity-secured VC: Yes, when the document conforms and is secured (VC 2.0 text) · JOSE/COSE-secured VC: Yes, when the document conforms and is secured (VC 2.0 text) · EIP-712 signed or on-chain registry attestation: Not by itself; needs a VC envelope or an EVM-aware verifier (analysis)
Cross-family compatibility · Data Integrity-secured VC: Lists JWT, JOSE and COSE compatibility as a non-goal (Data Integrity explainer) · JOSE/COSE-secured VC: Separate specification in the same working group (Data Integrity and JOSE/COSE explainers) · EIP-712 signed or on-chain registry attestation: Outside both W3C families unless wrapped (analysis); chain-bound only when the optional domain fields carry chainId and verifyingContract (EIP-712)
Revocation channel · Data Integrity-secured VC: credentialStatus, for example a bitstring list at 1 bit per credential (VC 2.0 text; status-list explainer) · JOSE/COSE-secured VC: credentialStatus works the same way (VC 2.0 text) · EIP-712 signed or on-chain registry attestation: Registry state or events, for example the 3 ERC-1056 events (ERC-1056)
Replay or domain binding · Data Integrity-secured VC: Set by the cryptosuite's proof options (qualitative) · JOSE/COSE-secured VC: Set by the JOSE or COSE profile's headers and claims (qualitative) · EIP-712 signed or on-chain registry attestation: EIP-712 includes no replay protection of its own (EIP-712)
Verifier dependency · Data Integrity-secured VC: Understanding every JSON-LD context used (VC 2.0 text) · JOSE/COSE-secured VC: A JWT or COSE implementation (analysis) · EIP-712 signed or on-chain registry attestation: Offline key recovery for a personal-wallet EIP-712 signature; RPC access to the right network for registry state or a registry-backed DID (analysis; did:ethr spec)

Qualitative cells carry no number because no cited source gives one; "analysis" marks this piece's reading.

Platform Signal. FiduWork describes its reputation layer as on-chain, DID-anchored, portable and backed by verifiable credentials, on top of USDC milestone escrow in its Sepolia beta, which lists 1,200+ freelancer profiles and $2.4M+ in on-chain payments. Disputes go to an Aragon-OSx panel of 3, 5 or 7 jurors inside the disclosed 72-hour voting window. Per the published reputation piece, the exact credential fields are configured in the deployed issuer contract; the DID method and proof format are not disclosed, and none of the three is covered by this piece's illustrative mapping.

Which regulations apply when a work credential carries personal data?

In the EU, a work credential can fall under data protection law once its identifiers can single out a freelancer. Personal data, under Article 4(1) of the General Data Protection Regulation, means information relating to an identifiable natural person, including one identified by reference to an online identifier. Article 17 gives the data subject a right to obtain erasure of personal data without undue delay where 1 of 6 listed grounds applies.

Why identifiers alone can be personal data

A wallet address or DID tied to a freelancer's work history is the kind of online identifier that definition names, so the subject DID can make a technical record personal. The pattern to ask any platform about keeps claims and evidence off-chain, puts only commitments or status bits on-chain, and documents what happens when a freelancer asks for erasure. It is not a description of FiduWork's design.

Compliance corner. For EU data subjects, the Article 17 right to erasure is not unconditional: paragraph 3 lists 5 exceptions, including processing needed for the establishment, exercise or defence of legal claims (erasure provisions of Regulation (EU) 2016/679). Whether a dispute record falls within one, and whether a hash or status bit is itself personal data, are questions for counsel. The engineering point is analysis, not law: an issuer cannot erase what it wrote to an immutable ledger. For credentials presented as evidence, Article 45b of Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183 on the European Digital Identity Framework, provides that an electronic attestation of attributes shall not be denied legal effect or admissibility as evidence in legal proceedings solely because it is in electronic form or does not meet the requirements for qualified attestations. That is the closest EU category an evaluator would raise with counsel; this piece does not claim a reputation credential is one, or that FiduWork issues one.

Where to go next on FiduWork

Start with the issuance path for DID-anchored, wallet-bound credentials, then the reputation schema built to resist wash ratings. The deposit-to-release escrow walkthrough gives the baseline states, and how a 3, 5 or 7 juror panel reaches a ruling covers dispute mechanics.

Read the Protocol Reference. Open the Sepolia beta and check any credential claim against the deployed issuer and escrow contracts before you trust a single field. Open the app.

Sources

Update Log

2026-10-07: Published.