Overview
This section outlines the step-by-step process for verifier registrars to onboard with the Google Wallet Identity service.
As a verifier registrar (for example, an IDV company verifying on behalf of other entities), you act as your own Certificate Authority (CA), signing identity requests for the downstream End Relying Parties (RPs) you manage.
Onboarding process
Step 1: Business review and Terms of Service (ToS)
- Vetting: Google will review your vetting processes and security standards.
- Sign the ToS: You must sign the Google Wallet Verifier Registrar Terms of Service.
Step 2: Trust establishment (Root CA setup)
Google Wallet uses a Chain of Trust model.
- Submit Root Certificate: Provide your Root CA certificate to Google.
- Google will add your root certificate to the Google Wallet trust store, allowing it to verify any certificates you issue to your End RPs.
Step 3: End RP onboarding
For each End RP you sign for, you must:
- Inform Google: Use the designated intake form (coming soon!) to notify Google of the new RP and its intended use case.
- Configure Metadata: Populate the RP's display information (Name, Logo, Privacy Policy URL) and set a globally unique Distinguished Name (Subject) in their certificate.
Technical specifications
A. Certificate profile
Requests must be signed by standard X.509 v3 certificates containing a custom Google extension:
- Custom Extension OID:
1.3.6.1.4.1.11129.10.1 - Content: A SHA256 hash of the
RelyingPartyMetadataBytes, encoded in an ASN.1OCTET STRING.
B. Metadata schema (CBOR)
Metadata must be encoded in CBOR format.
; in CDDL for CBOR encoding
; schemaVersion = "v1"
RelyingPartyMetadataBytes = #6.24(bstr .cbor RelyingPartyMetadata)
RelyingPartyMetadata = {
"schema_version": tstr,
"display": DisplayInfo,
"aggregator_info": DisplayInfo ; Optional: include to show your branding alongside the RP
}
DisplayInfo = {
"display_name": tstr,
"logo_uri": tstr, ; See note below on brand guidelines
"privacy_policy_uri": tstr
}
The logo_uri must follow Google Wallet Brand Guidelines.
C. OpenID4VP integration
Include the base64url encoded metadata in the client_metadata object:
{
"client_metadata": {
"vp_formats_supported": { ... },
"gw_rp_metadata_bytes": "<base64url encoding of RelyingPartyMetadataBytes>"
},
"nonce": "...",
"response_mode": "dc_api",
"response_type": "vp_token"
}
Compliance and revocation
- Abuse Monitoring: Google monitors for malicious RP activity and will notify you of any detected abuse.
- Prompt Revocation: You are required to promptly revoke certificates for abusive RPs and publish an updated Certificate Revocation List (CRL).
- Auditing: Google maintains anonymized logs to ensure RP requests match their registered use cases.
Next steps
To begin onboarding, contact your Google representative with your proposed Root CA certificate and your initial list of End RPs.