This page answers frequently asked questions about integrating with Google Wallet for Digital Identity and Credentials.
Onboard & Get Started
Q: What is the step-by-step process for a new partner to onboard as a Relying Party (RP)?
A: Refer to the steps at: Accepting IDs from Wallet Online.
Q: What is the typical duration for the RP onboarding process?
A: Typically onboarding should take 3-5 business days.
Q: How can we track the status of our Relying Party (RP) application after submission?
A: If you have not heard back after 5 days, please reach out to our support team on wallet-identity-rp-support@google.com.
Q: Where can we find the RP onboarding form and the official developer documentation?
A:
- Onboarding Form: Google Wallet Identity Relying Partners Contact Form
- Developer Documentation: Digital Identity Overview
Q: How will the information we provide (like Product Name and Logo) be used in the product experience?
A: The Product Name and Logo are displayed on the user-facing consent screen to help users identify which Relying Party is requesting their digital ID. URLs and policy links may also be featured in the product experience.
Q: Do we need to sign the Terms of Service if we only plan to use the sandbox environment for development and testing?
A: No, accepting the Terms of Service is not a required step for testing.
Q: Where can we find a reference implementation, sample code, or a demo application to get started?
A:
- GitHub Repository: Identity Reference Implementation.
- Test Website: verifier.multipaz.org
Verifier Registrars
Q: What is the Verifier Registrar and how does it work?
A: The Verifier Registrar acts as a Certificate Authority that onboards downstream clients (End RPs). The End RP does not interact directly with Google Wallet.
Q: What is the specific onboarding process for a Verifier Registrar and their downstream clients?
A: Refer to the steps at: Verifier Registrar Guide.
Q: How does it differ from a direct RP integration?
A: Verifier Registrars manage the trust relationship for their clients and handle the integration with Google Wallet on their behalf, whereas direct RPs manage their own configuration with Google.
Q: In the Verifier Registrar, who gets allow listed in Google's configuration: the Verifier Registrar, the end RP, or both?
A: Google allowlists the Verifier Registrar's Root CA certificate. The Verifier Registrar then issues new leaf certificates for each downstream End RP.
Q: How does the data flow between the end RP, the Verifier Registrar, and Google Wallet?
A: The Verifier Registrar sends the API request to Google Wallet for the End RP. Google Wallet returns encrypted credential data to the Verifier Registrar, who then processes it and sends the final signal to the End RP.
Q: For white-labeled solutions, is it required to show the Verifier Registrar's name in the user consent flow, or can it just be the end RP's name?
A: No. The Verifier Registrar can choose not to display their details.
Q: What are the permitted key types and curves for Root CAs and RP Certificates?
A: Certificates should be generated using P-256 / ECDSA.
Q: Can we use intermediate signer certificates between our Root CA and RP leaf certificates?
A: Yes. You can securely store a long-lived root certificate (e.g., in an HSM) to infrequently sign operational intermediate certificates. Those intermediate certificates can then be used to sign end-RP leaf certificates, allowing for easier rotation in the event of a breach without affecting the root.
Q: What is the required lifetime for certificates?
A: A 10-year lifetime is perfectly acceptable for a Root CA certificate. End-RP leaf certificates should generally follow a ~1-year renewal timeline to ensure they can be efficiently rotated if issues arise.
Q: Do we need to manage a separate leaf certificate for each individual Relying Party (RP) customer?
A: Yes. For the initial launch period, aggregators must manage separate certificates for each downstream RP. This enables per-RP display configurations and accurate abuse tracking. While this adds operational overhead at scale, we intend to revisit potential alternatives (such as using RP metadata hashes) following the initial rollout.
Q: Are partners permitted to have multiple active certificates simultaneously?
A: Yes, the configuration supports any number of active certificates per RP or aggregator, which is useful for partners operating under various business names.
Q: How should the Distinguished Name (Subject) be formatted?
A: The Distinguished Name must be globally unique per partner. This serves as a static identifier that Google uses to monitor incoming partner requests and ensure ecosystem trust.
Q: How does domain binding work? Do origins need to be embedded in the certificate?
A: Domains don't need to be embedded directly within the certificate itself. Instead, domain verification is performed using the expected origins parameter within the API call. Furthermore, multiple domains can be seamlessly associated with a single certificate. For unsigned requests, binding is executed using the Domain or App package name alongside a fingerprint.
Q: Can aggregator details be omitted from the verification UI for a white-labeled experience?
A: Yes, aggregator information (such as name, logo, URL, and privacy policy) is completely optional within the verifier metadata. This enables a fully white-labeled solution where only the end-RP details are displayed to the user.
Q: What do we need to provide to begin testing in the Sandbox environment?
A: From a technical standpoint, you only need to provide your Sandbox Root Certificate. The Sandbox is designed to identically mirror the production environment.
Q: How does the onboarding process differ for Verifier Registrars (Aggregators) compared to direct RPs?
A: Aggregators undergo a slightly modified process. After executing the specific Verifier Registrar Terms of Service, the intake is split into two parts: a primary form to establish your status as a Verifier Registrar, followed by a streamlined form required for each individual RP you onboard. Each RP submission typically requires a video recording of the integration, and the review process generally takes 2-3 business days.
Q: Can we onboard customers who intend to act as intermediaries or resell verification services to other entities?
A: No. Google's current model and preference is to work directly with Verifier Registrars (aggregators) and their direct end-RPs, rather than supporting nested reseller or intermediary models.
Technical Integration & API
Q: What is the underlying protocol for requests? What versions are supported?
A: The primary protocol is OpenID for Verifiable Presentations (OpenID4VP) version 1.0.
Q: Which ISO 18013-7 annexes (e.g., Annex B, C, D) does Google support for mDL presentation?
A: Google supports Annex D [currently in draft] (OpenID4VP using DC API).
Q: How do we correctly structure an API request to ask for multiple credentials in a single user presentation?
A: Both credential types should be requested within a single dcql query object in the same JSON request.
Q: Does the API allow requesting a generic credential without listing every possible credential type?
A: No.
Q: How does the API handle age verification? Can we request the exact date of birth, or only an "over X" signal?
A: Both are supported. You can request birth_date, age_in_years, or a privacy-preserving "over X" signal. Zero-Knowledge Proofs (ZKPs) can also be used for a true/false signal.
Q: What are the requirements for our PKI infrastructure?
A: RPs need a PKI to sign requests. Verifier Registrars act as their own CA.
Q: Can we use our own existing certificates, or do we need to get a new one signed by Google?
A: RPs need a new certificate signed by Google or a Verifier Registrar. For Verifier Registrars, Google will trust your Root certificate if you follow the "Trust Establishment" steps in the documentation.
Q: What is the recommended integration strategy for web versus Android app?
A: The entire request should be generated server-side. On Android, use the Credman API; on the web, use the Digital Credentials (DC) API.
Q: What debugging, logging, and observability tools are available for developers?
A: Partners can use the wallet-identity-rp-support@google.com support alias. No specific logging or observability tools are provided.
Credentials & Data
Q: Which digital IDs, issuers, and credentials are supported by country and region?
A: Find supported regions here: Supported Issuers and Certificates.
Q: When are you planning to support credentials from new countries or regions?
A: We are actively adding new regions; check the supported issuers page for updates.
Q: When a credential is updated by the issuer, does the end-user receive a notification?
A: Yes, the user is notified and the update is applied automatically.
Q: What credential data, if any, does Google store on its servers, especially in the context of GDPR?
A: Google does not save credential-related data on its servers; it is stored locally and securely on the user's device.
Testing & Environments
Q: How do we get access to a sandbox environment to test the full end-to-end flow?
A: The sandbox is open at: Sandbox Mode.
Q: What is the process for partners not based in an officially launched region to be added to the allowlist for testing?
A: Email the Gmail IDs of test wallets to wallet-identity-rp-support@google.com.
Q: What is the process to enable a test website or app for demo purposes, allowing anyone with a production credential to present it?
A: Partners must complete standard RP onboarding, including a sandbox video demonstration.
User Experience (UX)
Q: What is the user experience if a user doesn't have a digital ID or the Google Wallet app installed when they initiate a verification flow?
A: Users without the app are directed to the Play Store. Those without an ID can create one in-flow using the half-screen UI.
Q: Can we programmatically detect if a user has a digital ID in their Wallet before showing them the verification option?
A: No, the API must be user-invoked to protect privacy.
Q: Can we require the user to unlock their device with a biometric before presenting a credential?
A: User authentication (biometric, PIN, or pattern) is required by default and cannot be disabled.
Q: Is it possible to customize the order of requested attributes on the user consent screen?
A: No, Google Wallet reorders them alphabetically.
Security & Compliance
Q: Our use case involves re-sharing user data with third parties. Is this permitted under the Terms of Service?
A: Yes, restrictions may apply, see our terms of service for more details.
Q: What documentation is available regarding the security, reliability, and accessibility of the digital identity solutions for our compliance purposes?
A: Partners can reference Trail of Bits security reviews.
Advanced Features & Roadmap
Q: What are the capabilities of Zero-Knowledge Proofs (ZKP) for privacy-preserving age verification?
A: Zero-Knowledge Proof (ZKP) is a cryptographic method that allows an individual (the prover) to prove to a verifier that they possess a certain piece of identity information or meet a specific criterion (e.g., are over 18, hold a valid credential) without revealing the actual underlying data itself.
Q: How are different versions of the ZK circuits handled?
A: RPs must implement ZK verifier services to request the latest available circuits.
Q: How does credential sharing and management work across multiple devices, such as a phone and a wearable?
A: Credentials are provisioned to a single device and cannot be shared.
Others
Q: How does Google handle ID pass revocations if a passport is revoked?
A: Users can delete passes from Google Account settings; lost devices can be reported to revoke credentials.
Q: How is mDL revocation handled? Is it realtime?
A: It can be user-triggered or pushed by the issuer (DMV). It is real-time if the device is online; otherwise, short-lived security objects (MSOs) will expire.
Q: What is the key rotation policy for RPs?
A: Annual rotation is recommended.
Q: What is the minimum Android version supported for the Digital Credentials API?
A: Android 9 (API level 28) and higher.
Q: What is the minimum Chrome version that supports the Digital Credentials API?
A: Chrome version 128 and higher.
Q: Which Browsers support the Digital Credentials API?
A: You can find browser support details here: https://digitalcredentials.dev/ecosystem-support
Q: Which users will have the ability to add an ID when a new country is launched?
A: Access is based on the user's country setting in the Play Store.
Q: Does the Digital Credentials API work with iOS?
A: Yes, The API works using supported browsers like Safari. However OpenID4VP is not supported by Apple.