Flavio Espinoza

Identity and Single Sign-On | OpenID Connect — The front door. Nothing in Exemplar is reachable without a valid session, and the session is anchored to a real identity provider rather than a password table we own.

1. A.Hand-built because of Koa's onion model -- Koa's async/await middleware suspends at `await next()` and unwinds back through each layer, which buys clean downstream/upstream control and a single top-level try/catch over the whole stack, but it also meant no off-the-shelf OIDC module. I implemented the relying-party layer directly against Koa's `ctx`, including session context, token storage, and custom route matching. It was the first auth layer I had ever built, and building it by hand is how I learned single sign-on.
2. B.The full OIDC handshake, from the spec -- the authorization-code flow end to end: the provider redirect, the code-for-token exchange with a signed client assertion, ID-token structure and claims validation, and userinfo retrieval, implemented from the OAuth 2.0 and OpenID Connect specs rather than a library.
3. C.Security implemented by hand -- JWT signature verification on the tokens, state and nonce validation to mitigate replay and CSRF on the callback, and token introspection against the provider on every protected request so a revoked or expired session is caught immediately. Strict cryptographic, token, and state validation, with no check left optional.
4. D.Standardized on Okta as the control -- I shipped the custom layer while the team's PingFederate effort stalled (a low-level protocol engine being bent into an ontology layer), then my colleague and I convinced the CTO to adopt Okta, whose Universal Directory normalized the schemas behind a clean API and removed the configuration bottleneck, freeing the backend team to focus on the trust network. The two providers ran side by side through the migration: the token request branches by provider -- a client-secret-basic exchange for the federation server, a signed client-assertion (client-secret-jwt) for Okta -- behind one interface.
5. E.One provider-routing trick -- the OAuth `state` value carries the provider name as a prefix (`provider___<random>`), and the callback splits it back out to recover which provider answered. That single seam is how additional OIDC providers slot in behind the same contract without the rest of the application knowing which one handled the login, and it doubles as the per-request CSRF/replay nonce store.
6. F.Single logout, by the spec too -- logout is RP-initiated: the layer builds the provider's end-session URL with the `id_token_hint`, a post-logout redirect, and a fresh `state`, so signing out of Exemplar signs the session out at the identity provider, not just locally.

The Mock Network Seam | Contract-First Backend — The decision that let the application ship before the network it depends on existed. The network's responses were specified as a schema, and a Node server served that schema as realistic JSON.

1. A.Schema marked out first -- we agreed on exactly what the trust network (a Go service) would return, concretely a GraphQL `resolved_person` + `trust_summary` projection: the resolved person with its value, relationship, and association claims each attributed to an issuing source, paired with a `trust_summary` carrying a separate rating per claim. It was a shape I knew first-hand from contributing schemas to the network itself, and I built a Node server that emitted it as fixtures.
2. B.Real plumbing written underneath -- the actual request code to the live endpoints sat in place beneath the fixtures the entire time, so the mock and the live path shared one code shape.
3. C.Go-live is a URL swap -- promoting from demo to production meant pointing one endpoint at the real network instead of the mock, with no rewrite of the application that had already been built and tested against the contract.

Publishing and Discovery | Read and Write to the Network — Exemplar is not a read-only viewer over the network -- it is a full client to it, with a write path that publishes new subjects into the network and a read path that discovers and resolves them back out. Both sit behind the same swappable seam as the trust query, so both were built against fixtures first.

1. A.Ingest, the write path -- the add-person and add-organization flows assemble a subject and its claims into a single authorization-data-object graph, wrap each claim as a signed verifiable credential (carrying its evidence and what the issuer is accountable for), and publish that package to the network, which links it into the global trust graph. Onboarding a subject and registering it in the network are one action; the response comes back as the full ingest payload so the result is inspectable end to end.
2. B.The publish is signed by the same login -- the ingest request is authorized with the issuer's OIDC ID token, so the identity that proves who you are is the same identity that signs what you publish. The front door and the write path share one trust anchor instead of two.
3. C.Discovery, the read path -- a discovery service resolves a subject and its trust anchors, with separate lookups for the value, relationship, and association claims attached to it, plus the organization and person directory queries that back the summary tables. This is the layer that turns "who is this?" into the resolved record the UI renders.
4. D.The trust query on top -- the discovery results are projected through the GraphQL `resolved_person` + `trust_summary` query (see the seam above), which is the single shape the whole front end is written against. Read, write, and resolve all speak the same contract, which is why the mock-to-live swap was one URL and not three.

Dashboard and Global Trust Graph | React + Redux + D3 — The operator's interface -- where a logged-in user sees the trust the network has assembled about a person and acts on it.

1. A.Full React/Redux operational UI -- a multi-section dashboard (global trust graph, record descriptors, add person, add organization, issue claims) with the multi-step verification wizard built as Redux-driven flows.
2. B.Custom D3.js trust-graph visualization -- the resolved identity is rendered as a graph of claims, each scored on multiple independent trust scales (an identity-assurance level, a letter grade, an accreditor rank) and attributed to the source that asserted it, so the UI shows not just a fact but how much to believe it and why.
3. C.Drill-down into the underlying records -- from the graph a user opens the source records behind a person, including FHIR healthcare records (diagnostic reports and family-history lists) rendered straight from the raw resource JSON, and documents addressed by content hash, so the trust summary is always traceable back to the actual evidence.
4. D.Authorized records and consent -- record access runs through an authorized-records request and a consent flow (including consent revoke), so a viewer sees a person's healthcare records only under an explicit, revocable grant. This is the "consent" half of the network made concrete in the UI.
5. E.Live data over GraphQL -- the front end consumes the `resolved_person` + `trust_summary` query through an Apollo GraphQL client with a websocket subscription link, so the graph and tables update in place as claims and ratings change rather than on a manual refresh.

The Trust Data Model | Verifiable Claims — The spine the whole system is expressed in -- one JSON-LD vocabulary so that statements made by different organizations merge into a single graph about one subject.

1. A.One vocabulary, three claim kinds -- value claims (a property of a person, such as an age threshold), relationship claims (person to person, such as patient-of-clinician), and association claims (person to organization), all in the same shape so they compose.
2. B.Evidence is first-class -- a claim can carry how it was verified (document check, in-person proofing, a request for another person to confirm it) and what the issuer is accountable for, so the model captures not just what is claimed but how strongly and on whose word.
3. C.Verifiable, then accredited -- claims cross the network inside a signed envelope that proves who issued them, tracking the emerging W3C Verifiable Credentials model so an external party can trust a credential without trusting us.

Identity Verification | Document and Second Channel — Proofing the real human behind the session, beyond the login, so a claim can be backed by actual evidence.

1. A.Document and biometric capture -- a Jumio-based flow with in-browser webcam capture for government-ID verification, the path behind a "I verified their identity from their ID" proofing claim.
2. B.Second-channel verification -- a Twilio phone and SMS one-time-code flow as an independent "we reached this person on this number" evidence channel.
3. C.Wired to the model -- each verification maps directly onto the data model's proofing annotations, so proving an identity and recording how it was proven are the same act.

Backend and Delivery | Koa, Docker, CI — The server tier and the pipeline that shipped it -- a thin, well-bounded API plus the mock data server, packaged to deploy as one artifact.

1. A.Koa API, domain-per-folder -- a composed router with helmet/cors/body-parsing that also serves the built React app, with each concern (auth, identity, claims, verification, ingest) in its own module behind a thin controller layer.
2. B.One configuration source -- every provider endpoint and secret reference lives in a single YAML file that compiles to runtime config with environment-variable interpolation, so secrets arrive at container start and never live in the repo.
3. C.Dockerized with a CI gate -- a single release image with secrets injected at runtime, built by a two-stage pipeline where the test suite must pass before the image is built and pushed, with pass/fail reported to the team in Slack.

What it shows — Exemplar is the proof that I own a feature the whole way down -- front end, backend, the stand-in for a backend that is not built yet, and the pipeline that ships it -- and that I will build the hard thing from scratch when that is what it takes to actually own it. I had never written an auth layer, so I wrote one by hand from the spec, learned single sign-on at the protocol level, and then cut the thrash by steering us onto Okta so the rest of the team could focus on the real differentiator. And I never let the part that was not built yet block the part that had to ship: the mock-network seam let me deliver and demo the entire product ahead of the backend, then go live by changing one URL. Build it to understand it, prove one path and make it the control, and ship ahead of your dependencies -- that is how I work without a spec and without waiting for permission.