Prompt and scope
The company wants to replace part of its document-verification flow with the browser-mediated Digital Credentials API. How would you decide whether to adopt it, start with presentation or issuance, and control compatibility and privacy risk?
What the interviewer evaluates
- Separating API capability, credential ecosystem, and business outcomes instead of treating a draft standard as a ready-made network.
- Distinguishing presentation and issuance journeys and their different partners and risks.
- Quantifying coverage, completion, manual-review cost, fraud loss, and recovery paths.
- Putting data minimization, consent, alternatives, and stop conditions into the decision.
Clarifying questions
- Is the goal login, age assurance, account opening, or issuing a new credential?
- Which wallets, credential formats, and devices do target users have, and how will coverage be measured?
- Which fields are required, and which can use selective disclosure or manual review?
- What lets a user continue when verification fails, a wallet is unavailable, or a credential expires or is revoked?
30-second answer framework
I would start with a high-value, low-loss presentation journey as a small pilot rather than replacing every identity flow. Compare API, manual, and current paths on completion, time, cost, and fraud while measuring wallet and credential coverage. Data minimization, explicit consent, interoperability, and a fallback path are launch gates. Only after coverage, privacy, and operational metrics pass would I evaluate issuance or broader markets.
Step-by-step deep dive
1. Define the product boundary
The W3C 1 June 2026 Working Draft describes user-agent mediation for presenting and issuing digital credentials. It defines a coordination layer between the browser and credential ecosystem, not one universal document format, wallet network, or legal identity conclusion. Product discovery must test “the browser can start the flow” separately from “the business can trust the result.”
2. Separate presentation and issuance
Presentation asks for a credential the user already has; its risks center on wallet availability, user choice, disclosed fields, and verification. Issuance additionally needs issuer eligibility, credential format, key binding, lifecycle, and revocation, creating more partnership and compliance work. Start with one scenario using existing credentials instead of building an issuance network at the same time.
3. Set measurable decision gates
Use a control group and compare end-to-end completion, P50/P95 time, cost per verification, manual handoff, fraud rejection, and support volume. Segment by device, wallet, browser, and user cohort so averages do not hide gaps. Count API failure, user cancellation, expiry, and revocation separately; technical success is not business success.
4. Design privacy, trust, and fallback
Request only fields needed for the purpose, retain consent and purpose notices, and restrict credential data in logs. The verifier checks issuer trust, signatures, validity, and revocation rather than trusting client output. Unsupported devices, wallet rejection, and network failure use the existing manual or document path. Set stop thresholds for privacy incidents, complaints, or completion, and pause the pilot when any critical line is crossed.
High-quality sample answer
I would not replace identity verification just because a browser exposes an API. I would choose a presentation journey with existing credentials and bounded failure cost, measure wallet and browser coverage, and run a controlled comparison of completion, time, cost, manual handoff, and fraud. Presentation and issuance are separate decisions; issuance adds issuer eligibility, format interoperability, and revocation lifecycle work. The product requests only necessary fields, records consent, and the server verifies issuer, signature, validity, and revocation. Unsupported, cancelled, and expired flows return to the existing path. After coverage, privacy, and complaint stop lines are met, I would expand the market or evaluate issuance.
Common mistakes
- Treating the Working Draft as a universal network supported by every region, browser, and wallet.
- Mixing presentation with issuance and underestimating issuer, format, and revocation partnerships.
- Measuring only API call success instead of completion, manual handoff, and fraud outcomes.
- Logging raw credentials or requesting identity fields unrelated to the purpose.
- Having no non-API fallback, so unsupported devices cannot open an account.
- Running a pilot without a control group, market segments, or explicit stop lines.
Follow-up questions and answers
Why start with presentation?
It relies on existing credentials and wallets and has a smaller scope than an issuance network. It can validate user value, coverage, and verification quality before a separate issuance project.
How do you decide that coverage is sufficient?
Segment target devices, browsers, wallets, and user cohorts, then define a minimum completion rate from real funnel data rather than one compatibility table. Low-coverage users must retain an equivalent alternative.
When should the pilot stop?
Predefine thresholds for completion, privacy incidents, complaints, fraud loss, and manual cost. If a critical metric crosses its line, stop adding traffic, preserve audit evidence, and decide whether to fix or withdraw.