FAQ Identitas & Kredensial Digital

Halaman ini menjawab pertanyaan umum (FAQ) tentang integrasi dengan Google Wallet untuk Identitas dan Kredensial Digital.

Orientasi & Mulai

T: Apa proses langkah demi langkah bagi partner baru untuk melakukan aktivasi sebagai Pihak Tepercaya (RP)?

J: Lihat langkah-langkah di: Menerima tanda pengenal dari Wallet secara Online.

T: Berapa lama durasi umum untuk proses orientasi RP?

J: Biasanya, proses aktivasi memerlukan waktu 3-5 hari kerja.

T: Bagaimana cara melacak status permohonan Pihak Tepercaya (RP) kami setelah pengiriman?

J: Jika Anda belum menerima respons setelah 5 hari, hubungi tim dukungan kami di wallet-identity-rp-support@google.com.

T: Di mana kami dapat menemukan formulir aktivasi RP dan dokumentasi developer resmi?

A:

T: Bagaimana informasi yang kami berikan (seperti Nama dan Logo Produk) akan digunakan dalam pengalaman produk?

J: Nama dan Logo Produk ditampilkan di layar izin yang ditampilkan kepada pengguna untuk membantu pengguna mengidentifikasi Pihak Tepercaya mana yang meminta ID digital mereka. URL dan link kebijakan juga dapat ditampilkan dalam pengalaman produk.

T: Apakah kami perlu menandatangani Persyaratan Layanan jika hanya berencana menggunakan lingkungan sandbox untuk pengembangan dan pengujian?

J: Tidak, menyetujui Persyaratan Layanan bukan merupakan langkah yang diperlukan untuk pengujian.

T: Di mana kita dapat menemukan penerapan referensi, kode contoh, atau aplikasi demo untuk memulai?

A:

Registrar Pemverifikasi

T: Apa yang dimaksud dengan Registrar Verifikasi dan bagaimana cara kerjanya?

J: Pendaftar Verifikasi bertindak sebagai Otoritas Sertifikat yang mengaktifkan klien hilir (RP Akhir). RP Akhir tidak berinteraksi langsung dengan Google Wallet.

T: Apa proses aktivasi khusus untuk Registrar Verifikasi dan klien hilirnya?

J: Lihat langkah-langkah di: Panduan Pendaftar Verifikator.

T: Apa perbedaannya dengan integrasi RP langsung?

J: Registrar Verifikasi mengelola hubungan kepercayaan untuk klien mereka dan menangani integrasi dengan Google Wallet atas nama klien, sedangkan RP langsung mengelola konfigurasi mereka sendiri dengan Google.

T: Di Pendaftar Verifikasi, siapa yang masuk daftar yang diizinkan dalam konfigurasi Google: Pendaftar Verifikasi, RP akhir, atau keduanya?

J: Google memasukkan sertifikat CA Root Pendaftar Verifikasi ke daftar yang diizinkan. Kemudian, Pendaftar Verifikasi menerbitkan sertifikat leaf baru untuk setiap End RP hilir.

T: Bagaimana alur data antara RP akhir, Pendaftar Verifikasi, dan Google Wallet?

J: Pendaftar Verifikasi mengirim permintaan API ke Google Wallet untuk RP Akhir. Google Wallet menampilkan data kredensial terenkripsi ke Pendaftar Verifikasi, yang kemudian memprosesnya dan mengirimkan sinyal akhir ke RP Akhir.

J: Tidak. Registrar Verifikasi dapat memilih untuk tidak menampilkan detailnya.

T: Apa saja jenis dan kurva kunci yang diizinkan untuk CA Root dan Sertifikat RP?

J: Sertifikat harus dibuat menggunakan P-256 / ECDSA.

T: Dapatkah kami menggunakan sertifikat penanda tangan perantara antara sertifikat leaf RP dan CA Root kami?

J: Ya. Anda dapat menyimpan sertifikat root yang berlaku lama (misalnya, di HSM) dengan aman untuk menandatangani sertifikat perantara operasional yang jarang digunakan. Sertifikat perantara tersebut kemudian dapat digunakan untuk menandatangani sertifikat leaf RP akhir, sehingga memudahkan rotasi jika terjadi pelanggaran tanpa memengaruhi root.

T: Berapa masa berlaku yang diperlukan untuk sertifikat?

J: Masa berlaku 10 tahun dapat diterima untuk sertifikat CA Root. Sertifikat leaf End-RP umumnya harus mengikuti jadwal perpanjangan ~1 tahun untuk memastikan sertifikat tersebut dapat dirotasi secara efisien jika terjadi masalah.

T: Apakah kita perlu mengelola sertifikat leaf terpisah untuk setiap pelanggan Pihak Tepercaya (RP)?

J: Ya. Untuk periode peluncuran awal, agregator harus mengelola sertifikat terpisah untuk setiap RP downstream. Hal ini memungkinkan konfigurasi tampilan per-RP dan pelacakan penyalahgunaan yang akurat. Meskipun hal ini menambah beban operasional dalam skala besar, kami bermaksud untuk meninjau kembali potensi alternatif (seperti menggunakan hash metadata RP) setelah peluncuran awal.

T: Apakah partner diizinkan untuk memiliki beberapa sertifikat aktif secara bersamaan?

J: Ya, konfigurasi ini mendukung sejumlah sertifikat aktif per RP atau agregator, yang berguna bagi partner yang beroperasi dengan berbagai nama bisnis.

T: Bagaimana format Nama Pembeda (Subjek)?

J: Nama Pembeda harus unik secara global per partner. ID ini berfungsi sebagai ID statis yang digunakan Google untuk memantau permintaan partner yang masuk dan memastikan kepercayaan ekosistem.

T: Bagaimana cara kerja pengikatan domain? Apakah asal perlu disematkan dalam sertifikat?

J: Domain tidak perlu disematkan langsung dalam sertifikat itu sendiri. Sebagai gantinya, verifikasi domain dilakukan menggunakan parameter asal yang diharapkan dalam panggilan API. Selain itu, beberapa domain dapat dikaitkan dengan lancar ke satu sertifikat. Untuk permintaan yang tidak bertanda tangan, pengikatan dieksekusi menggunakan nama paket Aplikasi atau Domain bersama dengan sidik jari.

T: Dapatkah detail agregator dihilangkan dari UI verifikasi untuk pengalaman berlabel putih?

J: Ya, informasi agregator (seperti nama, logo, URL, dan kebijakan privasi) sepenuhnya bersifat opsional dalam metadata verifier. Hal ini memungkinkan solusi berlabel putih sepenuhnya yang hanya menampilkan detail RP akhir kepada pengguna.

T: Apa yang perlu kami berikan untuk mulai melakukan pengujian di lingkungan Sandbox?

J: Dari sudut pandang teknis, Anda hanya perlu memberikan Sertifikat Root Sandbox Anda. Sandbox dirancang untuk mencerminkan lingkungan produksi secara identik.

T: Apa perbedaan proses aktivasi untuk Registrar Verifikasi (Agregator) dibandingkan dengan RP langsung?

J: Agregator menjalani proses yang sedikit dimodifikasi. Setelah menyetujui Persyaratan Layanan Pendaftar Pemverifikasi tertentu, proses pendaftaran dibagi menjadi dua bagian: formulir utama untuk menetapkan status Anda sebagai Pendaftar Pemverifikasi, diikuti dengan formulir sederhana yang diperlukan untuk setiap RP yang Anda aktifkan. Setiap pengiriman RP biasanya memerlukan rekaman video integrasi, dan proses peninjauan umumnya memerlukan waktu 2-3 hari kerja.

T: Dapatkah kami mengaktifkan pelanggan yang berniat bertindak sebagai perantara atau menjual kembali layanan verifikasi kepada entitas lain?

J: Tidak. Model dan preferensi Google saat ini adalah bekerja secara langsung dengan Registrar Verifikasi (penggabung) dan RP akhir langsung mereka, bukan mendukung model reseller atau perantara bertingkat.

Integrasi Teknis & API

T: Apa protokol yang mendasari permintaan? Versi apa yang didukung?

J: Protokol utamanya adalah OpenID untuk Presentasi yang Dapat Diverifikasi (OpenID4VP) versi 1.0.

T: Lampiran ISO 18013-7 mana (misalnya, Lampiran B, C, D) yang didukung Google untuk presentasi mDL?

J: Google mendukung Lampiran D [saat ini dalam draf] (OpenID4VP menggunakan DC API).

T: Bagaimana cara menyusun permintaan API dengan benar untuk meminta beberapa kredensial dalam satu presentasi pengguna?

J: Kedua jenis kredensial harus diminta dalam satu objek kueri dcql dalam permintaan JSON yang sama.

T: Apakah API memungkinkan permintaan kredensial generik tanpa mencantumkan setiap jenis kredensial yang mungkin ada?

J: Tidak.

T: Bagaimana cara API menangani verifikasi usia? Dapatkah kami meminta tanggal lahir yang tepat, atau hanya sinyal "di atas X"?

J: Keduanya didukung. Anda dapat meminta birth_date, age_in_years, atau sinyal "lebih dari X" yang menjaga privasi. Zero-Knowledge Proof (ZKP) juga dapat digunakan untuk sinyal benar/salah.

T: Apa saja persyaratan untuk infrastruktur PKI kami?

J: RP memerlukan PKI untuk menandatangani permintaan. Registrar Verifikasi bertindak sebagai CA-nya sendiri.

T: Dapatkah kami menggunakan sertifikat yang sudah ada, atau apakah kami perlu mendapatkan sertifikat baru yang ditandatangani oleh Google?

J: RP memerlukan sertifikat baru yang ditandatangani oleh Google atau Registrar Verifikasi. Untuk Registrar Verifikasi, Google akan memercayai sertifikat Root Anda jika Anda mengikuti langkah-langkah "Pembentukan Kepercayaan" dalam dokumentasi.

J: Seluruh permintaan harus dibuat di sisi server. Di Android, gunakan Credman API; di web, gunakan Digital Credentials (DC) API.

T: Alat proses debug, logging, dan observabilitas apa yang tersedia untuk developer?

J: Partner dapat menggunakan alias dukungan wallet-identity-rp-support@google.com. Tidak ada alat logging atau observabilitas khusus yang disediakan.

Kredensial & Data

T: ID digital, penerbit, dan kredensial mana yang didukung menurut negara dan wilayah?

J: Temukan wilayah yang didukung di sini: Penerbit dan Sertifikat yang Didukung.

T: Kapan Anda berencana mendukung kredensial dari negara atau wilayah baru?

J: Kami terus menambahkan wilayah baru; periksa halaman penerbit yang didukung untuk mengetahui info terbaru.

T: Saat kredensial diperbarui oleh penerbit, apakah pengguna akhir menerima notifikasi?

J: Ya, pengguna akan diberi tahu dan update diterapkan secara otomatis.

T: Data kredensial apa, jika ada, yang disimpan Google di servernya, terutama dalam konteks GDPR?

J: Google tidak menyimpan data terkait kredensial di servernya; data tersebut disimpan secara lokal dan aman di perangkat pengguna.

Pengujian & Lingkungan

T: Bagaimana cara mendapatkan akses ke lingkungan sandbox untuk menguji alur menyeluruh yang lengkap?

J: Sandbox terbuka di: Mode Sandbox.

T: Bagaimana proses penambahan partner yang tidak berbasis di wilayah peluncuran resmi ke daftar yang diizinkan untuk pengujian?

J: Kirim email berisi ID Gmail dari test wallet ke wallet-identity-rp-support@google.com.

T: Bagaimana proses mengaktifkan situs atau aplikasi pengujian untuk tujuan demo, sehingga siapa pun yang memiliki kredensial produksi dapat menampilkannya?

J: Partner harus menyelesaikan proses orientasi RP standar, termasuk demonstrasi video sandbox.

Pengalaman Pengguna (UX)

T: Bagaimana pengalaman pengguna jika pengguna tidak memiliki tanda pengenal digital atau aplikasi Google Wallet terinstal saat mereka memulai alur verifikasi?

J: Pengguna tanpa aplikasi akan diarahkan ke Play Store. Pengguna yang tidak memiliki ID dapat membuatnya dalam alur menggunakan UI setengah layar.

T: Dapatkah kami mendeteksi secara terprogram apakah pengguna memiliki tanda pengenal digital di Wallet mereka sebelum menampilkan opsi verifikasi kepada mereka?

J: Tidak, API harus dipanggil oleh pengguna untuk melindungi privasi.

T: Dapatkah kami mewajibkan pengguna membuka kunci perangkat mereka dengan biometrik sebelum menampilkan kredensial?

J: Autentikasi pengguna (biometrik, PIN, atau pola) diperlukan secara default dan tidak dapat dinonaktifkan.

J: Tidak, Google Wallet mengurutkannya kembali menurut abjad.

Keamanan & Kepatuhan

T: Kasus penggunaan kami melibatkan pembagian ulang data pengguna kepada pihak ketiga. Apakah hal ini diizinkan berdasarkan Persyaratan Layanan?

J: Ya, pembatasan mungkin berlaku. Lihat persyaratan layanan kami untuk mengetahui detail selengkapnya.

T: Dokumentasi apa yang tersedia terkait keamanan, keandalan, dan aksesibilitas solusi identitas digital untuk tujuan kepatuhan kami?

J: Partner dapat merujuk pada peninjauan keamanan Trail of Bits.

Fitur Lanjutan & Roadmap

T: Apa kemampuan Bukti Tanpa Pengetahuan (ZKP) untuk verifikasi usia yang menjaga privasi?

J: Bukti Tanpa Pengetahuan (ZKP) adalah metode kriptografi yang memungkinkan seseorang (pembuktian) membuktikan kepada verifikator bahwa ia memiliki informasi identitas tertentu atau memenuhi kriteria tertentu (misalnya, berusia di atas 18 tahun, memegang kredensial yang valid) tanpa mengungkapkan data pokok yang sebenarnya.

T: Bagaimana cara menangani berbagai versi sirkuit ZK?

J: RP harus menerapkan layanan verifikasi ZK untuk meminta sirkuit terbaru yang tersedia.

T: Bagaimana cara kerja berbagi dan pengelolaan kredensial di beberapa perangkat, seperti ponsel dan perangkat wearable?

J: Kredensial disediakan untuk satu perangkat dan tidak dapat dibagikan.

Lainnya

T: Bagaimana cara Google menangani pencabutan tanda pengenal digital jika paspor dicabut?

J: Pengguna dapat menghapus kartu dari setelan Akun Google; perangkat yang hilang dapat dilaporkan untuk mencabut kredensial.

T: Bagaimana penanganan pencabutan mDL? Apakah ini real-time?

J: Dapat dipicu oleh pengguna atau didorong oleh penerbit (DMV). Objek keamanan berumur pendek (MSO) akan berakhir masa berlakunya jika perangkat sedang offline. Jika perangkat sedang online, objek keamanan berumur pendek (MSO) akan diperbarui secara real-time.

T: Apa kebijakan rotasi kunci untuk RP?

J: Rotasi tahunan direkomendasikan.

T: Berapa versi Android minimum yang didukung untuk Digital Credentials API?

J: Android 9 (level API 28) dan yang lebih tinggi.

T: Berapa versi Chrome minimum yang mendukung Digital Credentials API?

J: Chrome versi 128 dan yang lebih baru.

T: Browser mana yang mendukung Digital Credentials API?

J: Anda dapat menemukan detail dukungan browser di sini: https://digitalcredentials.dev/ecosystem-support

T: Pengguna mana yang dapat menambahkan ID saat negara baru diluncurkan?

J: Akses didasarkan pada setelan negara pengguna di Play Store.

T: Apakah Digital Credentials API berfungsi dengan iOS?

J: Ya, API berfungsi menggunakan browser yang didukung seperti Safari. Namun, OpenID4VP tidak didukung oleh Apple.