DEV Community: Darshit Khandelwal

Week -02

Darshit Khandelwal — Tue, 30 Jun 2026 14:21:36 +0000

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 Bitstring Status List spec (BitstringStatusListEntry). Worth revisiting before this goes to production, even if CredentialStatusList2020 stays as an internal placeholder for now.

2. Designing the SD-JWT disclosure policy

Quick primer on SD-JWT (Selective Disclosure JWT) for anyone unfamiliar: it lets a credential holder reveal only the claims required to verify something, without exposing everything else. A simple analogy — a bouncer checking you're over 18 doesn't need your phone number or home address, just proof of age.

So we split GitHubContributorCredential into two buckets: fields that are always disclosed (mandatory for the system to function) and fields that are selectively disclosed (hidden by default, to protect the developer's privacy).

Always disclosed

Issuer DID — Heka needs to know who issued the credential.
Issuance & expiry dates — Heka needs to verify the time limits.
Credential status — Heka must be able to check whether it's been revoked.
Contributor DID (sub) — the developer's public identifier on the Hedera network.

Selectively disclosed

GitHub username — a developer may want to prove they're an authorized LFDT contributor without permanently linking their Hedera DID to a public GitHub handle anyone could scrape.
GitHub numeric account ID — kept hidden unless the backend specifically needs to map the DID to an exact GitHub account.
Verified GPG fingerprint — only revealed when a repository explicitly needs it to verify a signed commit.

3. Example payloads and schema fixtures

Since we won't reveal every field by default, the SD-JWT payload replaces the hidden fields with an _sd (selective disclosure) array of hashes. A first pass looked like this:

{
  "iss": "did:hedera:testnet:z6MkhaXgBZDvotDkL5257faiztiuC2ZXOS",
  "iat": 1782604800,
  "exp": 1814140800,
  "sub": "did:hedera:testnet:z6Mkq...",
  "vct": "GitHubContributorCredential",
  "_sd": [
    "JzYx0... (hash of githubUsername)",
    "Qp2Lm... (hash of githubAccountId)",
    "Xy9Rq... (hash of gpgFingerprint)"
  ],
  "_sd_alg": "sha-256"
}

Public (always-disclosed) fields: iss (issuer), iat (issuance time), exp (expiry), sub (contributor DID), and vct (the credential type — since it's not in _sd, it's visible by default too).

Hidden fields: username, account ID, GPG fingerprint.

_sd_alg declares exactly which hash function was used, so the verifier knows how to check the disclosures later.

The verifier can't just brute-force the hidden fields from the hashes, since that would defeat the point — anyone could disclose everything by guessing. So each hidden claim is paired with a random salt before hashing: the disclosure is really hash(salt + claim_name + claim_value), and only the holder can produce the matching salt+value pair when asked to disclose it.

Where this landed

The finished schema fixture (JSON Schema for the credential subject):

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "GitHubContributorCredentialSubject",
  "description": "The exact rules for Heka GitHub Contributor claims",
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "pattern": "^did:hedera:.*",
      "description": "The developer's Hedera DID"
    },
    "githubUsername": {
      "type": "string",
      "minLength": 1
    },
    "githubAccountId": {
      "type": "integer",
      "minimum": 1
    },
    "gpgFingerprint": {
      "type": "string",
      "pattern": "^[0-9A-F]{16,40}$",
      "description": "Uppercase HEX fingerprint"
    }
  },
  "required": ["id", "githubUsername", "githubAccountId", "gpgFingerprint"],
  "additionalProperties": false
}

Note: the gpgFingerprint pattern allows 16–40 hex characters. A full GPG fingerprint is conventionally 40 hex characters (SHA-1, 160-bit); a 16-character value is really a GPG key ID, not a fingerprint. Worth tightening this to exactly 40 characters unless we genuinely want to accept short key IDs too.

And the final credential payload fixture, now including credentialStatus so it matches the "always disclosed" policy from Section 2:

{
  "iss": "did:hedera:testnet:z6MkhaXgBZDvotDkL5257faiztiuC2ZXOS",
  "iat": 1782604800,
  "exp": 1814140800,
  "sub": "did:hedera:testnet:z6MkqExampleDeveloperDID",
  "vct": "GitHubContributorCredential",
  "credentialStatus": {
    "id": "https://heka.network/status/123",
    "type": "CredentialStatusList2020"
  },
  "_sd": [
    "JzYx0aB9... (hash of 'githubUsername': 'darshit2308')",
    "Qp2LmC4... (hash of 'githubAccountId': 4115704)",
    "Xy9RqZ1... (hash of 'gpgFingerprint': '3AA5C34371567BD2')"
  ],
  "_sd_alg": "sha-256"
}

These live in the repo as:

heka-identity-service/src/credentials/fixtures/github-contributor-credential.schema.json — the JSON Schema defining what a valid GitHubContributorCredential subject looks like, the same way a government ID schema defines which fields (name, date of birth, etc.) must be present.
heka-identity-service/src/credentials/fixtures/mock-sd-jwt-payload.json — a mock GitHubContributorCredential for a fictional contributor, used across tests.

4. Validating the model with Jest

This was my first time writing Jest tests, so a quick summary of what I learned.

We use AJV (Another JSON Schema Validator) to check whether a piece of JSON data conforms to a given JSON Schema — for example, confirming githubAccountId is actually an integer, as the schema requires.

The tests live in heka-identity-service/src/credentials/credential-subject.spec.ts. The .spec.ts suffix is Jest's convention for a specification (test) file, and its job is to verify the schema behaves correctly against both valid and invalid inputs.

A small helper does the heavy lifting of turning a fixture file into a usable object:

const loadFixture = (fileName: string) => {
  return JSON.parse(readFileSync(join(__dirname, "fixtures", fileName), "utf8"));
};

From there, the test suite exercises as many valid and invalid permutations of the credential subject as we could think of — missing fields, wrong types, malformed DIDs, malformed fingerprints — to make sure AJV rejects exactly what it should and accepts exactly what it should.

5. did:hedera DID creation and deterministic verification-method selection

Using the operator credentials agreed on in Week 1, we created and resolved a did:hedera DID on Hedera testnet, with proof of creation and resolution captured via HashScan and the resolver output.

We also implemented deterministic verification-method selection, so signing operations always pick a specific, well-defined verification method rather than relying on array position (e.g., verificationMethod[0]), which isn't guaranteed to be stable. Tests now cover both DID resolution and this selection logic.

The code-level detail for both of these — along with the full schema, fixtures, and Jest suite above — is in the PR linked below; it's a better reference than a paraphrase here.

PR for reference: hiero-ledger/heka-identity-platform#179

Week - 1 (Phase 1)

Darshit Khandelwal — Mon, 22 Jun 2026 14:10:41 +0000

Week 1 of My LFDT Mentorship: Architecture, Hedera, and Getting Everything Running

Welcome to the first post of my LFDT (Linux Foundation Decentralized Trust) mentorship blog! Each week I'll be writing about what I built, what I learned, and — honestly — what confused me along the way.

Week 1 was all about planning, architecture decisions, and setting up the groundwork before any real code gets written. No flashy features yet, but a lot of important decisions that will shape everything that comes after. Let's get into it.

The Week at a Glance

Here's a quick summary of everything on my plate this week:

Align the implementation plan with my mentor and confirm the interpretation of Issue #87
Finalize the target architecture for the whole project
Sort out the Hedera testnet setup and operator credentials
Understand the revocation strategy and its scope during mentorship
Set up the local Heka development environment
Install and configure a GitHub App for local testing
Create a webhook fixture repository for replaying PR events
Prepare a PR slicing plan for incremental delivery

Aligning with the Mentor & Locking Down the Plan

The week started with a sync with my mentor to get the implementation plan nailed down. The good news is, the week-by-week plan has been finalized after a proper discussion, and the interpretation of Issue #87 has been confirmed. With the plan locked in, I can move forward with confidence in the coming weeks.

Deciding the Target Architecture

One of the bigger decisions this week was figuring out where everything actually lives, contributor onboarding, GitHub integration, credential issuance, DID management, and verification policy logic all need a home.

Here's what we landed on:

heka-identity-service — This is where the core modules live: contributor onboarding, credential issuance, DID management, and verification policy logic. All of this gets built as a dedicated module within this repo.
A separate GitHub repository — The GitHub integration code (the Probot app, webhook handling, check-run posting) lives in its own repo, completely separate from heka-identity-service. This keeps Heka clean and focused on identity, and makes the GitHub-specific code easier to extend or extract later.

There are still a few grey areas to iron out over the next couple of weeks, but the overall direction is clear and agreed upon.

Understanding Hedera: Consensus Nodes vs Mirror Nodes

If you're already familiar with Hedera's architecture, feel free to skip ahead to the next section!

Before I explain how Hedera fits into this project, let me share something I was confused about early on: what's the difference between a consensus node and a mirror node?

Unlike older blockchains (like Ethereum) that use a single node type for everything, Hedera splits the workload into two completely different node types to keep the network fast.

1. Consensus Node — The Write Database

This is where you send new transactions (like creating an account or logging a DID document to the ledger).
Its job is to receive the transaction, verify it, agree on a timestamp, and write it to the ledger as fast as possible.
Because it's hyper-focused on speed and new writes, it's not great at answering questions about old or historical data.

2. Mirror Node — The Read Database

The mirror node sits quietly alongside the consensus node and constantly copies (mirrors) every approved transaction.
Its only job is to take that raw blockchain data and organize it into a highly searchable traditional database (like PostgreSQL), and expose a REST API that developers can query.
Important caveat: you cannot send new transactions to the mirror node — it's strictly read-only.

How This Applies to Our Project

In practice, the two node types serve two completely different purposes in our system:

Writing (creating/updating a DID): Our backend uses the consensus node, authorized via operator credentials from our .env. The SDK signs the transaction automatically using the operator key.
Reading (showing transaction history or verifying an identity): The frontend makes a standard HTTP GET request directly to the mirror node's REST API — completely bypassing the consensus node.

Our .env will look something like this:

HEDERA_NETWORK=
OPERATOR_ID=
OPERATOR_KEY=
NODE_IP=
MIRROR_NODE_IP=

HBAR Balance & Revocation Strategy

After clarifying with my mentor Alexander, I now have the credentials for the operator account. The account comes loaded with enough test HBAR tokens to cover everything I need during development — creating, updating, and querying DIDs. So the token balance won't be a blocker at all.

On the revocation front: implementing a full, hardened VC revocation mechanism is out of scope for this mentorship. The focus right now is on building a working prototype, so revocation will either be tackled in the second half of the mentorship or saved for post-mentorship work. For now, the expectation is lightweight documentation and runbook-level treatment — not a working mechanism.

Setting Up the Local Dev Environment

This was the most hands-on part of the week. Getting the local Heka environment running required wiring together three tools: Nginx, Ngrok, and a GitHub App. Let me walk through how they fit together.

The Nginx Routing Rules

Nginx listens on Port 8080 and applies two simple routing rules to every incoming request:

# Rule 1: Route GitHub Webhooks → Probot GitHub App (Port 3000)
location /api/webhook {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# Rule 2: Route everything else → Heka Core Backend (Port 3001)
location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

In plain English:

If the request is to /api/webhook → forward it to the GitHub App on Port 3000
Everything else → forward it to the main Heka backend on Port 3001

Why Ngrok Is Necessary

Here's the catch: Nginx only listens on localhost. But when GitHub fires a webhook event, "localhost" from GitHub's perspective means GitHub's own servers — not your machine. It would send the event into the void, find nothing, and drop it silently.

Ngrok solves this by creating a public tunnel from your local Port 8080 directly to the internet:

ngrok http 8080

Ngrok gives you a temporary public URL — something like https://something.ngrok-free.app. You paste this into your GitHub App's webhook URL settings. Now the entire flow works end-to-end:

GitHub fires a PR event
        ↓
Hits the public Ngrok URL
        ↓
Ngrok tunnels it to Port 8080 on your local machine
        ↓
Nginx reads the request and applies the two routing rules
        ↓
Correct service handles it (Port 3000 or 3001)

A one-liner to remember the whole pipeline:

GitHub labels it and sends it → Ngrok blindly transports it → Nginx reads it and diverts it.

Webhook Fixture Repository

To avoid opening real pull requests every single time I want to test webhook handling, I created a dedicated fixture repository for generating and replaying PR events during development.

You can find it here: darshit2308/Heka-Webhook-Fixture

The PR Slicing Plan

To keep development incremental and mentor-reviewable, I've planned out the PR delivery sequence. This is tentative for now, but here's the rough order:

ADRs and credential profile documentation
Deterministic DID verification method helper and Hedera secret validation
GPG challenge lifecycle module with tests
GitHub App adapter skeleton and check-run creation (separate repo from Heka, per mentor direction)
GitHub OAuth and contributor binding
Contributor credential OID4VCI support
Heka Web Wallet prototype (lives inside the Heka repository; non-Askar key management)
Heka Web UI onboarding flow
Repository config parser and policy schema
OID4VP verification integration (Web Wallet as the primary target)
Lifecycle and recovery documentation (runbooks; no revocation implementation)
E2E test suite, docs, and final demo artifacts

Looking Ahead

Week 1 was heavy on planning, decisions, and setup — but that's exactly how it should be. A solid foundation now means fewer surprises (and fewer painful rewrites) later. Starting next week, the real implementation begins: ADRs, the DID helper utilities, and the first PR going out the door.

Stay tuned for Week 2!

This post is part of my ongoing LFDT Mentorship 2026 blog series. Feel free to reach out if you have questions or want to discuss anything covered here!

Starting My LFX Mentorship Journey: Building Contributor Identity Verification for Hiero

Darshit Khandelwal — Sun, 14 Jun 2026 19:25:09 +0000

Today, June 15th, 2026, I officially start my 6-month LFX mentorship under the Linux Foundation Decentralized Trust (LFDT) program. I will be working on a project called Hiero Contributor Identity Verification Prototype, under the guidance of my mentor Alexander Shenshin.

*## What am I building, and why does it matter? *
In open-source projects, anyone can open a pull request. But how does a project maintainer know that the person submitting code is actually who they claim to be? Right now, most projects simply trust GitHub usernames, which can be faked, compromised, or shared.
This project solves that by building a real identity verification layer on top of GitHub's contribution workflow. When a contributor opens a pull request, instead of just trusting their username, the system cryptographically verifies their identity using:

Decentralized Identifiers (DIDs) anchored on the Hedera blockchain
Verifiable Credentials issued through the OID4VCI standard
GPG cryptographic signatures tied to their GitHub account
Verifiable Presentations verified at pull request time through OID4VP

In simple terms, a contributor proves they are who they say they are, once, and that proof travels with every pull request they open, automatically. (There is another alternative, that is, instead of storing the proof, we can create the proof of user's validity on dynamically, after every Pull Request opened. Although, this is an open question and would be clarified by the end of week-1).

*## What will I be documenting here? *
I plan to post weekly updates throughout this mentorship. Each post will cover what I built that week, the architectural decisions I made and, more importantly, why I made them, and what I learned or found difficult.
Specifically, I will be tracking:

1) Weekly progress updates on implementation
2) Architecture Decision Records explaining key technical choices
3) Demo videos after every major milestone
4) Honest reflections on blockers, mistakes, and lessons learned

I have some experience working with decentralized identity standards like OID4VCI and OID4VP from my previous projects, so i will try to explain the concepts too in as much detail as possible, to help the community.

## How can these posts be useful to you
These posts can be a genuine learning chance for individuals who are thinking to study concepts like DIDs, and dive into blockchain.
If you are working on decentralized identity, Hedera, open-source tooling, or LFX mentorship yourself, you can follow along.

Thanks a lot for reading until here!!
We can connect here:
linkedin: https://www.linkedin.com/in/darshit-khandelwal-49bb25288
GitHub: https://github.com/darshit2308