Prompt and context
Gaming, content, and online-pharmacy sites need to check whether a user is 13, 16, or 18. The user holds a credential from a government or trusted issuer. The service must support multiple issuers, offline recovery, revocation, and abuse investigations.
What the interviewer tests
They are testing credential lifecycle, data minimization, trust roots, replay resistance, availability, and regulatory audit trade-offs. W3C VC 2.0 defines issuer, holder, and verifier; the Digital Credentials API lets a user agent mediate presentation.
Questions to clarify
Ask about thresholds, jurisdictions, credential sources, anonymous proof, failure UX, and retention. Clarify whether the site needs exact age or only a boolean result, and whether high-risk cases require manual review.
30-second answer
“An issuer creates an age-bearing verifiable credential, and the wallet presents only a threshold proof, not birth date or name. For every request the verifier creates a nonce and audience, then checks signatures, expiry, status, and purpose binding; the service stores only minimal audit events. I would start with one jurisdiction and threshold, measure success, replay rejection, false rejection, and leakage, then expand issuers and offline flows.”
Step-by-step deep dive
Define participants and trust roots
The issuer attests facts, the holder wallet controls disclosure, and the verifier site makes a one-time request. The platform maintains trusted-issuer metadata and key rotation without re-proving identity itself.
Design minimal disclosure
Return a derived “at least 18” assertion, credential type, and expiry rather than birth date, name, or stable identifier. Define schemas by jurisdiction and threshold so extra fields never enter logs.
Prevent replay and correlation
Bind every presentation to a nonce, audience, callback origin, and short expiry. Reject a reused nonce; avoid reusable correlators and issue a verifier-specific pseudonym when needed.
Verify signatures and status
Check the credential chain, algorithm, issuer trust, expiry, and revocation or suspension status. Status responses may be cached only with a freshness limit; a failed lookup should fail closed or require review according to risk.
Handle offline and recovery
Offline verification uses signed material and a recent status snapshot with an expiry, never indefinite trust. A lost wallet requires re-binding or re-issuance on a new device without lowering the threshold.
Set audit and data boundaries
Audit requester, policy version, result, and verification time, not the raw credential or birth date. Protect a controlled correlation token for abuse investigations with separate storage, encryption, and access controls.
Model answer
I would model issuer, holder, and verifier. The issuer publishes an age-bearing VC; the wallet presents only the threshold result. The site creates a nonce and audience for each request, verifies signature, trust directory, expiry, and status, and rejects replay. The service stores policy version, result, and time, never birth date or raw credentials. Offline mode uses a freshness-limited status snapshot, and recovery re-binds or re-issues. Pilot one jurisdiction, measure success, false rejection, replay rejection, and privacy audits, then expand.
Common mistakes
Collecting a full identity document
That violates minimization and increases leakage and cross-site tracking; an age conclusion is usually enough.
Checking only the signature
A valid signature does not prove expiry, non-revocation, or correct audience. Status and purpose must be checked.
Reusing a global user identifier
Global identifiers let sites correlate users. Use a verifier-specific pseudonym or one-time assertion.
Trusting stale offline status forever
Revocation and key rotation invalidate old state. Offline material needs expiry and an upgrade path.
Follow-up questions
What if an underage user lacks a credential?
Offer re-issuance, regulated manual review, or a clear denial path; do not require uploading a full identity document to the platform.
How do you handle a malicious site replaying a credential?
Bind presentation to verifier, nonce, and short TTL; monitor repeated nonces and abnormal origins, and revoke trust configuration when needed.
What if jurisdictions have different rules?
Make policy version, threshold, and issuer directory configurable; include jurisdiction and policy version in the result instead of hard-coding one global rule.
How do you prove privacy protection?
End-to-end tests should ensure logs, analytics, and errors contain no birth date or stable identifier; audit disclosed fields and status lookups regularly.