Interview with Scott Goci, Founder, Aho

This interview is with Scott Goci, Founder, Aho.

Scott, you’re a Founder in the computer software space with deep experience in web application security, open source, and ML—how do you introduce your current work in instant‑verify, tamper‑proof digital credentials to someone new to the field?

The easiest way I’ve found is to start with something most people already understand: tap-to-pay.

Twenty years ago, when you paid with a credit card, the merchant took a carbon copy of your card — your full card number sitting in their files, waiting to be lost or stolen. Today, you tap your phone. The merchant gets a confirmation that you paid; they never see your card number. Nothing for them to lose.

Identity verification is still stuck in the carbon-copy era. When a website needs to confirm you’re over 18, you upload a copy of your driver’s license. When an employer needs to verify your degree, they ask for documents or call the registrar.

Aho is the tap-to-pay version for identity. We’re a verifiable credentials platform: the issuing authority — a DMV, a university, an employer — cryptographically signs a credential that lives in the user’s phone wallet. When someone needs to verify something about that user, they get a signed yes/no answer back: “Yes, this person is over 18,” signed by the DMV. “Yes, this person went to the University of Michigan,” signed by the university. The verifier never sees the underlying document. There’s nothing for them to store, and nothing for hackers to steal.

The reason this matters more every year: AI is making document inspection an arms race. AI can generate a convincing fake driver’s license. It can’t fake a cryptographic signature.

What milestones in your journey from early‑stage startups and full‑stack development (PHP/Rails/React) to credential tech most shaped how you build and evaluate these systems today?

TrueJob taught me that building startups is harder than building software.

A lot of engineers want to design the perfect modular software system at the start—partly because it feels like progress, and partly because complexity reads as competence: complex systems make you look smart. But “build it and they will come” doesn’t work. You ship something, you watch what actually matters to your customers, and you let that pull the architecture in a direction you couldn’t have predicted. The flip side is that you have to be deliberate about what you ship in the first place—once even one paying customer relies on something, you’re committed to maintaining it forever. Both halves—letting customers shape the system, and being careful what you commit to—are what shape how I evaluate any new feature today.

Shogun taught me how to scale beyond myself.

I joined as one of the early engineers at Shogun. Very quickly, I went from working directly with the founders to leading teams, and what I had to learn was that no feature can live only in my head. Anything you build that only you know how to maintain—a tool you brought in, a pattern you used, a system you architected—becomes a single point of failure when the team is bigger than you. Every choice has a handoff cost.

Playboy taught me how to build robust systems on top of unreliable ones.

Adult content companies can’t use most of the tools mainstream engineers take for granted—payment processors, content hosting, fraud tools, etc. The vendors you are allowed to use tend to have worse APIs, more downtime, and rougher SLAs. So a meaningful chunk of the engineering work becomes designing around their limitations: redundancy, smart failure handling, and building better systems on top of worse ones to keep the customer experience intact. That changed how I evaluate any system: you don’t get to assume your dependencies are reliable. If they fail, what’s your fallback?

Building on that, when you kick off a tamper‑proof credential project, what initial threat model do you adopt and why?

Honest answer: I don’t always start with a threat model. I start with the customer and the use case, and the threat model falls out of that.

Tamper-proof credentials cover a huge range of stakes. A state government issuing digital driver’s licenses is defending against organized identity theft, state-level adversaries, and large-scale fraud. A startup issuing employee credentials is defending against degree fraud, casual misuse, and the occasional disgruntled ex-employee. The technical building blocks are the same, but the specific defenses that matter look very different.

What I do start with is a few questions about the flow: who can issue this credential and how do they prove they’re legitimate? Who can verify it, and what do they actually learn in the process? What happens when something needs to be revoked? And what happens if the issuer’s signing keys are compromised—because that’s the worst-case scenario for any credential system, and your design has to assume it will eventually happen. Those questions surface the threat model better than starting from ‘what are we afraid of.’ Start with fear and you overengineer. Start with the actual flow and you build the right defenses for it.

The other thing I think about constantly is the security-vs-UX trade-off. Security that breaks the user experience gets bypassed—users find workarounds, or they just don’t adopt the system. The whole reason cryptographic verification is more secure in practice than document upload is because it’s also easier on the user.

SSL is a good example of how this plays out. There was real pressure to adopt HTTPS for years—Snowden revelations, Google’s ranking signal, the whole HTTPS-everywhere movement—but it took Let’s Encrypt making certificates free and auto-renewing for HTTPS to actually become table stakes. Pressure alone doesn’t drive adoption, but pressure plus near-zero friction does.

The flip side: every layer of friction you add for security has to be justified by an actual threat. Pile on extra authentication steps or restrictions that don’t match the realistic risk, and users will route around them—and you end up with all the friction of a secure system with none of the actual security benefit.

So when I evaluate a credential project, I think to myself: who’s using this, what’s the realistic adversary, and can we defend against them without making the system harder to use than the status quo it’s replacing. The threat model has to be calibrated to those answers.

For instant verification at scale (think millions of checks per day), what architectural pattern has worked best for you in production and why?

In the document-verification world, every check is a round trip: a user uploads their ID, your server uploads it to a vendor (Persona, Checkr, etc.), the vendor runs OCR plus ML plus fraud checks, and the vendor returns yes/no. You’re paying per check; latency lives in the vendor’s infrastructure; and if the vendor has an outage, your verification pipeline goes with it. We experienced this at Playboy — vendor downtime was a real operational concern, and per-check pricing sets a hard floor on unit economics that becomes painful as you scale.

Luckily, with cryptographic verification, the structure is inverted. A signed credential arrives at your service, and verifying it involves signature math against the issuer’s public key. There is no vendor in the hot path and no per-check cost. It’s CPU-bound, stateless, and horizontally scalable in the same way SSL termination or JWT validation is.

That leaves three things you have to engineer for at scale:

1. Issuer key resolution.

   For JWT-based credentials (SD-JWT VC, JWT-VC), the issuer’s metadata advertises a JWKS endpoint (a JSON Web Key Set) that you verify signatures against. For mDoc (ISO 18013-5), it’s an X.509 chain rooted in a national IACA. Treat it as a cacheable HTTP resource — pull once, cache aggressively, and serve from the CDN edge.

2. Revocation.

   You can’t call the issuer per check — that shifts the dependency back into the hot path. Bitstring Status List holds up: the issuer publishes a bitmap of revocation state for every credential. Fetch it once, cache it, and check a bit. One request can give you the status of millions.

3. Trust lists.

   At platform scale, you have many issuers, not one. “Is this issuer one I trust?” needs to be a cached lookup against a published trust list. The EUDI architecture is built around this — verifiers resolve trust anchors from signed Trusted Lists.

Once those three pieces are in place, verification takes a millisecond or two of CPU per check, making this scalable to millions of checks (or more) per day.

Staying practical, how do you decide between user‑controlled wallets and server‑side custody for credential storage in a real product?

Honest answer: there are three distinct decisions buried in this question. “Custody” gets used to mean different things, and the right answer depends on which one you mean.

1. Issuance-time claim data.

   The issuer needs the underlying facts about the user to sign a credential in the first place. That data is server-side, always — no architectural choice here.

2. At-rest signed credential.

   The user picks where the signed credential lives — a device wallet (Apple, Google, EUDI Wallet) or a cloud wallet that stores it encrypted at rest. Device wallets give maximum sovereignty; cloud wallets give easier recovery and multi-device support. Both are legitimate as long as the user chooses the custody. What to avoid is parallel storage: an issuer keeping a full copy of every signed credential beyond what revocation needs.

3. Verifier-side storage.

   This is where the architectural win actually lives. In the document-upload world, every verifier ends up with a copy of the user’s driver’s license image — a breach pattern that keeps repeating across the industry. In the VC world, the verifier holds at most the disclosed claims and a verification log.

The principle that ties axes 2 and 3: who’s the legitimate issuer, and what does each party need?

For an externally issued credential — a DMV license, a university degree — the user picks the wallet (device or cloud, their call). The verifier never retains the credential, only the disclosed claims and the verification result. The DMV keeps what it always kept; the verifier holds far less than in the document-checking world of before.

For a credential your platform issues about the user — a loyalty tier, an employer badge — server-side storage on your platform is expected. You’re the issuer; you’re already authoritative for that data.

The UX exception: for users without a wallet, you need a fallback for first-time presentation — usually a cloud wallet flow that prompts them to provision a device wallet afterward. Forcing wallet install before first use is usually a conversion killer!

Drawing on your open‑source experience, which standards or protocols have been must‑adopt for interoperability, and how did you evaluate their maturity before committing?

For Aho, the must-adopt standards have been OpenID4VCI and OpenID4VP for issuance and presentation, W3C Verifiable Credentials and ISO 18013-5 mDoc as the primary credential formats, and the standard cryptographic primitives behind them — JOSE on the JSON side, COSE on the CBOR side. In addition, there are supporting specifications for revocation, trust frameworks, and PKI that any production deployment needs.

When evaluating maturity before committing, two things mattered. First, a real standards body behind it — W3C, IETF, ISO, etc. Second, regulatory or large-platform backing: EUDI specifying its required formats and US state mDL programs converging on ISO 18013-5 force you to adopt those if you want to work in those ecosystems.

Looking at hiring workflows and ATS integrations you’ve touched, what single step should builders take this quarter to earn trust and default adoption of digital credentials by employers?

The reason employers don’t default-adopt digital credentials today comes down to switching costs. The existing flow is integrated with the systems they already use, has audit trails their compliance team already accepts, and works — slowly, expensively, but predictably. To win default adoption, the credential-verification flow has to slot into that workflow without making anyone re-engineer.

What that looks like in practice: an OpenID-style flow where the candidate clicks “verify my degree,” gets redirected to their wallet, approves selective disclosure, and the employer gets back a signed yes/no plus an audit record. Same shape as “Sign in with Google” — five seconds, no document upload, no emailing the registrar back and forth.

The trust unlock is being measurably faster, cheaper, and more audit-defensible than the status quo on a single verification employers already do. Pick one, beat the existing flow on those three axes, and the broader adoption follows from there.

The mistake to avoid: trying to be a universal credential layer first. Employers buy outcomes on specific workflows. The pitch that lands is “this specific verification just got 90% faster and the audit team is happy.”

Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?

A decade ago, encrypted web traffic was a minority; today it’s nearly universal, driven by friction removal, platform pressure, and security incidents that make the alternative untenable.

We’re in an SSL-circa-2014 moment for identity. The infrastructure exists; the work for the next few years is building the verification flows on top of it.