Building the GitHubContributorCredential: SD-JWT Design and Hedera DID Verification

This week's goals were:

• Define the complete GitHubContributorCredential schema, including contributor DID, GitHub username, GitHub numeric account ID, verified GPG fingerprint, issuer DID, issuance time, expiry, and credential status reference.


• Design the SD-JWT disclosure policy and determine which claims are always disclosed versus selectively disclosed.


• Create example credential payloads and schema fixtures that can be reused throughout implementation and testing.


• Validate the credential model with unit tests covering valid and invalid credential subjects.


• Create and resolve a did:hedera DID on Hedera testnet using the operator credentials agreed during Week 1.


• Capture proof of successful DID creation and resolution through HashScan and resolver outputs.


• Implement deterministic verification-method selection so signing operations never depend on array ordering such as verificationMethod[0].


• Add tests covering DID resolution and verification-method selection behavior.

Here's how the week went, day by day.

1. Defining the GitHubContributorCredential schema

GitHubContributorCredential holds every field our system needs to identify a contributor. To keep it usable by the Heka backend service, we split the fields into two categories: standard VC metadata (the outer wrapper) and the credential subject (the actual identity claims).

Standard VC metadata

• 
  Issuer DID — the did:hedera identifier of the Heka platform issuing the credential.


• 
  Issuance time — the ISO 8601 timestamp of when the proof was generated.


• 
  Expiry — when the credential needs to be renewed (e.g., six months or a year from issuance).


• 
  Credential status reference — a pointer to the revocation registry on the Hedera network, so Heka can revoke the credential if a contributor's keys are compromised.

Credential subject (the contributor claims)

• 
  Contributor DID — the developer's personal did:hedera identifier.


• 
  GitHub username — the human-readable handle (e.g., darshit2308).


• 
  GitHub numeric account ID — the immutable integer ID GitHub assigns to every account. This matters because a user can change their handle, but the numeric ID never changes.


• 
  Verified GPG fingerprint — the cryptographic fingerprint of the key used to sign commits, proving the holder controls the private key registered against their GitHub account.

Putting it all together, here's the schema draft:

{

  "@context": [

    "https://www.w3.org/2018/credentials/v1",

    "https://w3id.org/security/suites/ed25519-2020/v1"

  ],

  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",

  "type": ["VerifiableCredential", "GitHubContributorCredential"],

  "issuer": "did:hedera:testnet:z6MkhaXgBZDvotDkL5257faiztiuC2ZXOS",

  "issuanceDate": "2026-06-28T00:00:00Z",

  "expirationDate": "2027-06-28T00:00:00Z",

  "credentialStatus": {

    "id": "https://heka.network/status/123",

    "type": "CredentialStatusList2020"

  },

  "credentialSubject": {

    "id": "did:hedera:testnet:z6Mkq...",

    "githubUsername": "darshit2308",

    "githubAccountId": 4115704,

    "gpgFingerprint": "3AA5C34371567BD2"

  }

}

A quick walkthrough for anyone new to verifiable credentials:

• 
  @context tells any parser "read this using W3C Verifiable Credentials rules" — it gives the document its vocabulary.


• 
  id is just a unique identifier for the credential document itself.


• 
  type declares what kind of credential this is.


• Everything else maps to the eight fields described above.

Note for later: CredentialStatusList2020 isn't an officially standardized status type — the current W3C recommendation is the

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen