A student ID added to a phone wallet and a scanned ID saved as a PDF may describe the same person, but they are not interchangeable files. Chrome's latest identity update makes that distinction important for universities, employers and service teams designing document workflows.
What Chrome 155 changes
On 23 October 2026, Chrome announced that Digital Credentials API issuance is enabled by default in Chrome 155. An issuer's website can start a request that lets the user choose a compatible wallet app and add a digital credential. Chrome describes the API as a transport layer; the wallet still retrieves the credential from the issuer using an issuance protocol such as OpenID for Verifiable Credential Issuance.
Chrome documents two paths. On Android, the request can pass to the operating system's credential manager and show compatible wallets. From desktop Chrome, a user can scan a QR code and finish on an Android device; Bluetooth is used to confirm that the devices are nearby. Each issuance request requires its own user action, such as clicking an “add” button.
This is not a general replacement for every identity document, upload form or PDF archive. A relying organisation still decides what evidence it accepts, and an issuer must operate the required service.
Keep the wallet flow and document record separate
1. Ask what the recipient actually accepts. If an official service supports a wallet credential, follow that service's stated process. Do not substitute a screenshot or printed wallet screen unless the recipient explicitly accepts it. Conversely, a portal asking for a PDF does not automatically accept a digital-credential exchange.
2. Confirm the issuer and purpose. Start from the organisation's known website or app and read what information will be issued. A browser prompt does not make an unfamiliar issuer trustworthy. Avoid sharing more identity information than the stated task requires.
3. Preserve meaningful choice. The Chrome flow is user-mediated: the person chooses a wallet and consents. A cancelled request, unsupported browser or missing compatible wallet needs a clear fallback, not a vague “identity failed” message. The documented same-device flow is Android-based, so teams should not assume identical support on every phone or browser.
4. Verify completion on the server. Chrome warns that the object returned to the webpage is not the issued credential and does not necessarily mean issuance finished. The issuer's server knows when the wallet retrieves the credential from its endpoint. A success screen should reflect that verified state instead of only a completed browser call.
5. Define any separate PDF record. Some authorised workflows still need a human-readable receipt, case note or evidence pack. State why that record is needed, who may access it and how long it is retained. Keep it clearly labelled as a static record—not as the wallet credential or proof that a live verification succeeded.
Important limits
The W3C Digital Credentials specification dated 20 October 2026 is a Working Draft. W3C explicitly says it may change and should be treated as work in progress. Chrome 155 shipping one issuance path does not establish universal browser support, legal acceptance, accessibility or compatibility with every wallet and credential format. Cross-device use also depends on an Android device and Bluetooth under Chrome's documented flow.
If an authorised process produces a PDF receipt or reference copy, FileStation's PDF Reader can help inspect the exact pages before filing or sharing it. For a copy containing sensitive details, read Hiding PDF text is not redaction before release. FileStation does not issue, store or verify digital credentials and cannot determine whether an identity document is genuine.
The useful design principle is simple: use the credential protocol for the live wallet exchange, and treat any PDF as a separate document with its own purpose, access controls and review.