Handshake

• 

  Thumbnail Concept

• 

  Customer Approves One Allergy Constraint

• 

  Restaurant Receives Only the Approved Constraint

• 

  Kitchen Records the Preparation Decision

• 

  Customer Reviews and Can Revoke the Active Grant

• 

  Revocation Removes the Data and Locks Future Actions

Track: Identity. Lane: Build.

Inspiration

People with severe food allergies often have to repeat sensitive information across ordering apps, AI assistants, restaurant staff, and kitchens. They have little control over how much information is copied, who receives it, or how long it remains available.

A restaurant does not need a customer’s complete health profile. It needs one current fact for one purpose: the dietary constraint that applies to this order.

What it does

Handshake is a minimum-disclosure identity flow built with Egoist AI Passport.

The passport holder selects one dietary constraint, one restaurant recipient, one order purpose, and a fixed expiration time. The restaurant receives only that approved claim. It does not receive the holder’s other constraints, private conversations, or full personal profile.

For our proof case, a parent shares a peanut constraint for one restaurant order. Fieldline can verify that the holder approved the disclosure, that it applies to the selected order, and that access is still active.

The restaurant can record an outcome such as accept, request a preparation change, decline, or cannot determine. The holder can deny the original request or revoke an active grant, immediately preventing future use.

The identity claim is not that Handshake medically verifies an allergy. The claim is that the passport holder authorized this exact constraint for this exact recipient and purpose during this exact time window.

How we built it

We built a TypeScript protocol and two connected interfaces: a holder permission screen and a restaurant operations screen.

The protocol models passport claims, selected-field disclosure, scoped grants, expiration, revocation, recipient decisions, acknowledgements, and receipt previews. The restaurant interface remains locked until the holder approves the requested scope. After revocation or expiration, the disclosed value is removed and further restaurant actions are blocked.

Automated tests cover field minimization, denial, expiry, claimant-only revocation, invalid scope changes, restaurant outcomes, acknowledgements, and duplicate-event protection.

Challenges we faced

The hardest part was separating identity proof from agent authority. An AI assistant begins the request, but the AI is not the identity being proved. The holder and their disclosure choices remain at the center of the system.

We also had to prevent the demo from implying that a local browser event was an authenticated restaurant action. The current build is an interactive proof case, not a DoorDash integration or clinical verification system.

What we learned

Identity does not always require revealing a legal name or complete credential. In this case, useful identity means proving only the fact required for one decision while keeping everything else private.

We also learned that consent must remain changeable. A person needs to see what was requested, limit its purpose and duration, deny it, correct future passport data, and revoke active access.

What comes next

A production version would add authenticated restaurant identities, signed transport between services, persistent receipt delivery, and optional trusted issuers for claims that require independent verification.

This entry is for people with private dietary constraints, who need to prove that one active constraint applies to one order to a restaurant, so they can receive an informed response without giving away more context than necessary.

Built With

• html
• javascript
• typescript