Digital identity verification from the browser via Digital Credentials API: Designing age verification and KYC for clients in 2026

In Modernize authentication with passkeys, digital credentials, and more (2026-05-21), Chrome Developers explained developments in the web's Digital Credentials API. The core takeaway is that you can securely receive only the required attributes via a browser from identity credentials stored in a user's smartphone digital wallet (such as mobile driving licences mDL / ISO 18013-5 and various digital IDs). For instance, receiving only the fact that the user is "at least 18 years old" without passing their date of birth or full name itself—this is selective disclosure / data minimization. The implementation takes the form of passing a digital credential request to navigator.credentials.get(). What is crucial here is that this is completely distinct from passkeys (passwordless authentication = login). Whereas passkeys handle authentication ("who you are logging in as"), Digital Credentials handle attribute presentation and identity verification ("whether you meet attribute X"). Confusing the two during system design will lead to mismatched requirements.

In custom system development, age verification and identity verification (KYC) have repeatedly fallen into the trap of "having users upload ID images for manual visual inspection" or "entering dates of birth into fragile in-house forms," resulting in incidents where organizations hoard excessive personal information and take on massive risk. Supporting client web development and custom system development, we view this as a design challenge: "Can we design and deliver a secure, low-friction, legally compliant verification flow that receives only the necessary attributes and never retains them?" Login authentication was covered in Migrating to Passwordless Authentication with Passkeys (GH Media), while session and token handling was discussed in Security Auditing for Web Authentication and Session Management (GH Media). In this article, we outline the attribute presentation side as a custom development service package called "Digital Identity & Age Verification Implementation Support." Note that since legal requirements for identity and age verification vary by industry, prior legal review is an absolute prerequisite before implementation.

Why rebuild identity verification now

In other words, "being able to verify identity" and "being able to verify identity without hoarding personal information" are two entirely different things. In client work as well, "receiving only the necessary attributes, retaining nothing, and delivering the system with fallback paths in place for users without supported devices" has become a fundamental baseline of quality. This allows us to guarantee an "identity verification flow free of excessive personal data" as a deliverable.

What can be done with the Digital Credentials API

1. Selective disclosure (only required attributes = data minimization)

The greatest value is that "users can present only the attributes necessary for verification without handing over their entire name, date of birth, and address." For age verification, because it can be received virtually as a boolean flag confirming "at least 18 years old," there is no need to collect or retain excessive personal information. In client development, we narrow down what attributes are truly essential for the feature at the requirements phase to minimize the acquisition scope.

2. Presentation flow from mDL / digital wallets

Smartphones are increasingly equipped with digital wallets holding mDLs (mobile driving licences / ISO 18013-5) and various digital IDs. When a site requests specific attributes, the user explicitly approves the presentation, and the wallet responds with a cryptographically signed payload. The server then verifies the signature to confirm authenticity.

3. Application to age verification and KYC

The minimal invocation looks like the following. You pass the digital credential request to navigator.credentials.get() and verify the returned response on the server side.

// ブラウザ側: 必要な属性だけを要求する（例: 18歳以上であること）
const credential = await navigator.credentials.get({
  digital: {
    requests: [{
      protocol: 'openid4vp',
      data: {
        // 「18歳以上か」という属性のみを要求（生年月日そのものは要求しない）
        // 実フィールド名・プロトコルはウォレット/規格に合わせて定義する
      },
    }],
  },
});

// 受け取った応答はそのまま信用せず、サーバ側で署名・有効性を検証する
await fetch('/api/verify-credential', {
  method: 'POST',
  body: JSON.stringify({ response: credential.data }),
});

The key rule is never to trust the response solely on the front end. Verification must be performed on the server side, designed so that only the verification result (a "verified" boolean flag) is retained, while the attributes themselves are never stored. For the foundations of web security, please also consult Web Security Fundamentals (GH Media).

5 phases of our client offering: "Digital Identity & Age Verification Implementation Support"

Phase 1: Requirements and legal review (1 week)

• Clarifying the verification purpose (age verification / KYC / credential validation)
• Narrowing down strictly necessary attributes (minimizing acquisition scope)
• Reviewing industry-specific laws and guidelines (legal review required)
• Establishing fallback policies for users without supported devices

Phase 2: Design (1 week)

• Designing presentation flows and attribute schemas
• Drawing boundaries between retained and non-retained data (data minimization design)
• Designing server-side verification logic and signature verification
• Designing fallback flows (document submission, etc.)

Phase 3: Implementation (1–3 weeks)

• Implementing the presentation flow using navigator.credentials.get()
• Implementing signature and validity verification on the server side
• Implementing data models that store only the verification result flag
• Implementing fallback flows

Phase 4: Security verification (1 week)

• Testing against tampering, replay attacks, and spoofing
• Auditing whether excessive data is being retained
• Verifying audit logs and consent acquisition flows
• Confirming compatibility across devices and wallets

Phase 5: Operational handover (1 week + ongoing)

• Handing over operational runbooks and data retention policies
• Monitoring framework for regulatory revisions and standards updates
• Establishing operational flows for incidents and unsupported devices

Implementation and security standard package for client work

Which projects need this and which do not

Six clauses to include in client contracts

Client ROI estimate (assumed for services requiring identity verification)

Even with just an identity verification assessment (starting from 300,000 JPY), making visible which pieces of currently collected personal information are genuinely necessary is valuable in itself. Hoarded personal information demands its payment all at once whenever a breach occurs.

Five common pitfalls

Pitfall 1: Collecting too many attributes

If you collect full identity documents "just in case," you take on retention liabilities voluntarily. Request only the attributes necessary for validation.

Pitfall 2: Retaining attribute data

Leaving attributes stored after verification creates breach risk. Retain only the verified flag and discard the attributes.

Pitfall 3: Lacking fallback paths

Users without digital IDs will drop off. Always prepare alternative flows such as document submission.

Pitfall 4: Assuming supported devices and wallets

As adoption is still underway, a certain number of environments remain unsupported. Design branching logic on the assumption that devices may be unsupported.

Pitfall 5: Postponing legal review

Requirements differ by industry, leading to costly re-engineering later. Complete legal reviews prior to implementation.

90-day action plan

Conclusion: From hoarding identity documents to receiving and handing over only required attributes

With the Digital Credentials API, age and identity verification is shifting from an era of collecting and hoarding uploaded documents to an era of selectively receiving only required attributes without retaining them. From our perspective supporting client web development and custom system development, our "Digital Identity & Age Verification Implementation Support"—which minimizes acquired attributes, verifies them on the server, retains only results, and delivers systems equipped with fallbacks for unsupported devices—serves as our flagship offering to deliver identity verification free of excessive personal data. If you are also reviewing your login authentication architecture, please refer to Migrating to Passwordless Authentication with Passkeys (GH Media).

If you are looking to "make age verification safer and lower friction," "avoid holding excessive personal data during KYC," or "consult on whether Digital Credentials can be adopted," please feel free to reach out via our contact form. Please note that identity and age verification involve statutory requirements, so consider scheduling a legal review prior to implementation.

Sources

• Modernize authentication with passkeys, digital credentials, and more（Chrome Developers 2026-05-21）
• Migrating to Passwordless Authentication with Passkeys (GH Media)
• Security Auditing for Web Authentication and Session Management (GH Media)
• Web Security Fundamentals (GH Media)