How to Run an Identity and Privacy Hackathon Track

An identity challenge should produce more than another login page. The strongest tracks ask teams to improve a moment where trust breaks down: account recovery, consent, accessibility, fraud resistance, delegated access, or privacy-preserving onboarding.

The track also needs guardrails. Participants should be able to demonstrate a realistic flow without collecting real identity documents or exposing personal data. This guide gives organizers a practical structure for the brief, support plan, and judging rubric.

Start with one user problem

“Build something with identity” is too broad. Give teams a user, a moment, and a constraint.

Here are better starting points:

• Help a user recover an account without making takeover easier.
• Make a consent request understandable before the user agrees.
• Design an accessible passkey enrollment and recovery journey.
• Protect a sensitive action when a session may be compromised.
• Show who authorized an AI agent to perform a specific task.
• Onboard a user with synthetic verification data while collecting less information.

Let teams choose their implementation, but keep the judging question stable: does this build make the user journey more trustworthy?

Use synthetic users and mock identity data

Student events must not use real Aadhaar, PAN, DigiLocker, or KYC uploads. A demo does not need live personal data to prove that its flow works.

Provide synthetic user profiles, placeholder document states, and test-only verification outcomes. Label them clearly so screenshots and demos cannot be mistaken for production data. If a team brings its own dataset, organizers should confirm that the team has permission to use it and that the challenge does not require sensitive information.

NamoID sponsorship for student events follows this test-data-only rule. It protects participants, organizers, and the people whose data might otherwise be copied into a rushed prototype.

Give teams a buildable scope

A 24- or 48-hour event cannot produce a complete identity platform. Ask for one end-to-end journey instead:

User starts a sensitive action
  -> product explains why confirmation is needed
  -> user authenticates or gives consent
  -> product records the decision
  -> user sees the result and a recovery path

Teams can mock components outside their core idea. A project focused on consent copy does not need to build a cryptographic protocol. A project focused on token handling does not need a polished marketing site.

Publish what may be mocked, what must work, and what the judges expect to see in the demo.

Provide support in layers

Not every participant needs the same help. A useful track offers:

1. A short orientation. Explain the problem, safety rules, and judging criteria.
2. Starter resources. Provide sandbox access, sample flows, or framework-specific starting points where available.
3. Scheduled mentor hours. Let teams bring a narrow technical or product question.
4. A community path. Give participants a place to ask setup questions before and during the event.

For a NamoID-supported track, organizers may request sandbox access, starter kits, a workshop, and identity or privacy mentors where available. After applying, organizers should post the event name and dates in the NamoID Slack community for a quicker initial response. Participants can use the same community for setup questions and integration feedback. Formal confirmation still happens through the sponsorship conversation, and Slack does not replace the published route for reporting security or privacy issues.

Judge trust, not feature count

Publish the rubric before building starts. A 100-point rubric can keep judging concrete:

Do not award points for collecting more data, adding unrelated features, or using the largest number of sponsor products. Reward a smaller system with a clear threat model over a broad demo that hides its risks.

Ask teams to show the failure path

The happy path is only half an identity product. Each finalist should answer at least three questions:

• What happens when authentication or verification fails?
• What does the user do if they lose access?
• What data is retained, and why?

For consent projects, ask how a user changes or withdraws a decision. For agent-access projects, ask who is accountable for the agent and how its authority is limited. For recovery projects, ask how the design resists an attacker who already knows basic profile information.

These questions reveal more about a team’s judgment than another animation in the demo.

Confirm the sponsor contribution before promotion

NamoID is a startup and provides product-led, in-kind support based on event fit and team availability. Organizers may request:

• sandbox access for participants;
• starter kits or templates;
• an OAuth, passkeys, or trusted-onboarding workshop;
• mentors or judges;
• a focused identity, consent, or privacy prize track; and
• slides, a recorded introduction, or approved partner assets.

Cash, travel, venue costs, swag, and in-person attendance are not implied. Do not publish a NamoID prize, speaker, judge, or logo until it is confirmed.

For a broader explanation, read what NamoID provides to sponsored events. If this track fits your event, tell NamoID about the event, audience, and dates.