Panduan verifikator OpenID4VP: menerima EUDI Wallet

Terakhir ditinjau: 5 Oktober 2026 · Bukan nasihat hukum

OpenID4VP adalah cara situs web atau aplikasi meminta dompet untuk membuktikan sesuatu tentang seseorang, misalnya nama atau tanggal lahir. Verifikator menyebutkan kredensial dan klaim yang diinginkan, pengguna menyetujuinya di dompet, lalu dompet mengembalikan presentasi yang diperiksa verifikator secara kriptografis. Menurut spesifikasinya sendiri, protokol ini "defines a protocol for requesting and presenting Credentials" (mendefinisikan protokol untuk meminta dan menyajikan Kredensial).^[1]

Panduan ini ditujukan bagi pengembang yang membangun verifikator OpenID4VP untuk Dompet EUDI. Isinya mencakup request object, DCQL, mode respons, alur perangkat, pemeriksaan SD-JWT VC dan mdoc, aturan HAIP dalam hukum Uni Eropa, kesalahan umum, dan tempat untuk melakukan pengujian.

OpenID4VP dalam bahasa sederhana

OpenID4VP menggunakan kembali bentuk permintaan otorisasi OAuth 2.0. Verifikator meminta response type vp_token, dan respons yang berhasil wajib menyertakan parameter vp_token yang memuat presentasi.^[1] Tidak ada kode atau access token yang perlu dipertukarkan: data langsung tiba di dalam respons.

Dompet mengautentikasi pihak pengandal, memeriksa bahwa pihak pengandal tidak meminta lebih dari yang telah didaftarkannya, mengumpulkan persetujuan pengguna, dan menandatangani presentasi. Pihak pengandal kemudian memverifikasi tanda tangan penerbit, status pencabutan, dan pengikatan perangkat.^[3] Data identifikasi pribadi (PID) diterbitkan dalam dua format, yaitu SD-JWT VC dan ISO/IEC mdoc. Keduanya menggunakan hash bergaram (salted hash) sehingga pengguna dapat membagikan sebagian atribut dan menyembunyikan sisanya.^[5][3]

1. 10 Juli 2025Spesifikasi finalOpenID4VP 1.0 disetujui.
2. 22 Juli 2026DiterbitkanCIR 2026/1731 (diadopsi 15 Juli 2026) di Jurnal Resmi.
3. 23 Juli 2026ARF v3.0.0Rilis arsitektur saat ini.
4. 24 Desember 2026DompetMinimal satu per Negara Anggota.
5. 24 Desember 2027PenerimaanPihak pengandal swasta yang diregulasi.

Dari spesifikasi final hingga tanggal penerimaan oleh sektor swasta.^[2][3][4][5]

Cara kerja pertukaran dengan verifikator OpenID4VP

OpenID4VP menerbitkan desain referensi untuk mode respons direct_post. Dalam mode ini, dompet mengirim respons ke endpoint server, bukan melalui browser.^[1]

Desain referensi direct_post dalam OpenID4VP 1.0, bagian 13.3, versi sederhana.^[1]

• Buat nonce sebesar "setidaknya 16 byte acak yang baru dan aman secara kriptografis" untuk setiap permintaan.
• Kirim request-id dari response endpoint ke dompet sebagai state.
• Kembalikan redirect URI dengan response_code baru setelah dompet mengirimkan data.
• Ambil VP Token dengan transaction-id dan kode tersebut, lalu periksa nonce.

response_code mencegah session fixation, yaitu ketika penyerang meneruskan permintaan Anda ke dompet digital milik korban. Spesifikasi mencatat bahwa kode ini tidak membantu dalam alur lintas perangkat dan merekomendasikan mekanisme tambahan untuk kasus tersebut.^[1]

Objek permintaan OpenID4VP dan pengidentifikasi klien

client_id diawali dengan Client Identifier Prefix yang memberi tahu dompet cara mengautentikasi verifikator.^[1] Permintaan berukuran besar dikirim melalui referensi: dompet mengambil objek permintaan yang ditandatangani dari request_uri. Untuk kode QR, spesifikasi merekomendasikan direct_post dengan request_uri, karena permintaan tersebut "mungkin tidak muat dalam kode QR".^[1]

Prefiks Client Identifier, OpenID4VP 1.0 bagian 5.9.^[1]

Untuk verifikator EUDI, hukum Uni Eropa menentukan prefiksnya: sertifikat leaf "untuk digunakan dengan Client Identifier Prefix x509_hash wajib berupa sertifikat akses RP sebagaimana ditetapkan dalam ETSI TS 119 475", dan salah satu elemen verifier_info "wajib memuat sertifikat registrasi".^[5]

Kueri DCQL: minta apa yang Anda daftarkan

Digital Credentials Query Language (DCQL) adalah kueri JSON yang menyebutkan kredensial dan klaim yang Anda minta. Kueri ini memuat array credentials yang wajib dan array credential_sets yang opsional. Setiap kueri kredensial memerlukan id, format, dan objek meta.^[1] Contoh SD-JWT VC dari spesifikasi:^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

Untuk mdoc, formatnya adalah mso_mdoc dan meta memuat doctype_value.^[1] Untuk PID, ganti dengan jenis dan nama klaimnya. Atribut PID yang wajib adalah nama keluarga, nama depan, tanggal lahir, tempat lahir, dan kewarganegaraan.^[7]

• Nilai bawaan require_cryptographic_holder_binding adalah true. Pertahankan nilai ini: dengan nilai ini dompet mengembalikan bukti key binding.^[1]
• trusted_authorities hanya menyaring apa yang ditawarkan dompet. Verifikator "harus memverifikasi sendiri bahwa penerbit presentasi yang diterima tepercaya".^[1]
• Pihak pengandal "tidak boleh meminta pengguna memberikan data apa pun selain" data yang mereka daftarkan, dan dompet melakukan pemeriksaan.^[4][3]

Mode respons OpenID4VP

Mode respons menentukan cara VP Token dikirim kembali. Nilai bawaan untuk vp_token adalah fragment, yaitu di dalam fragmen redirect URI.^[1]

Mode respons dalam OpenID4VP 1.0.^[1]

Dengan direct_post, response_uri wajib ada dan redirect_uri tidak boleh ada. Jika tidak, dompet mengembalikan invalid_request.^[1] Sebagai contoh, EVO Wallet milik Moldova mendokumentasikan OpenID4VP 1.0 dengan direct_post.jwt dalam alur perangkat yang sama, mdoc ISO/IEC 18013-5 yang diprofilkan sesuai OpenID4VC HAIP 1.0, serta IETF Token Status List untuk pencabutan.^[11]

Perangkat yang sama, lintas perangkat, dan Digital Credentials API

ARF mencantumkan kombinasi jarak jauh yang didukung: OpenID4VP yang digabungkan dengan mekanisme transmisi berbasis pengalihan (redirect) dan skema URI kustom; OpenID4VP atau ISO/IEC 18013-7 yang digabungkan dengan W3C Digital Credentials API; serta, secara opsional, ISO/IEC 18013-7 dengan pengalihan dan skema URI kustom.^[3]

Tiga cara dompet menerima permintaan OpenID4VP.^[3][1][10]

ARF menyatakan bahwa skema URI kustom "tidak direkomendasikan untuk alur lintas perangkat" dan menyebut Digital Credentials API sebagai alternatifnya.^[3] Melalui API tersebut, dompet mengetahui origin verifikator sebagaimana diautentikasi oleh browser, "yang penting untuk ketahanan terhadap phishing".^[1] Spesifikasi W3C tersebut masih berupa draf.^[9] Yang dilihat pengguna di ponsel:

Verifikasi presentasi SD-JWT VC langkah demi langkah

Presentasi SD-JWT VC memuat JWT yang ditandatangani penerbit, disclosure yang diungkapkan pengguna, dan Key Binding JWT. Verifikator "WAJIB memvalidasi setiap Verifiable Presentation secara individual" dan menolak presentasi dengan nonce yang salah.^[1]

Pemeriksaan verifikator atas satu presentasi SD-JWT VC.^[1][3]

Tanda tangan penerbit. ARF menempatkannya di urutan pertama dalam daftar pemeriksaan pihak pengandal. Trust anchor berasal dari Trusted Lists (ETSI TS 119 612) dan Lists of Trusted Entities (ETSI TS 119 602).^[3]

Disclosure. Payload yang ditandatangani memuat array digest _sd. Setiap disclosure terdiri atas salt, nama klaim, dan nilai, misalnya ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].^[1] Hitung hash setiap disclosure dan temukan digest-nya. Jika tidak ada yang cocok, berarti penerbit tidak menandatanganinya.

Key Binding JWT. Jika holder binding diwajibkan, dompet "WAJIB mengembalikan SD-JWT dengan Key Binding JWT". nonce-nya harus sama dengan nonce permintaan Anda, dan aud-nya harus sama dengan Client Identifier Anda, atau jika melalui Digital Credentials API, dengan origin Anda yang diawali origin:.^[1] Contoh dari spesifikasi:

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

Pencabutan. Pihak pengandal memverifikasi bahwa penyedia "tidak mencabut PID atau atestasi tersebut".^[3] Sebagai contoh, EVO Wallet milik Moldova mendokumentasikan IETF Token Status List untuk keperluan ini.^[11]

Presentasi mdoc melalui ISO/IEC 18013-7, secara singkat

Untuk mdoc, VP Token memuat DeviceResponse dari ISO/IEC 18013-5 yang dienkode base64url dan "memuat tanda tangan atau MAC atas SessionTranscript", termasuk struktur handover OpenID4VP.^[1] Handover tersebut mengikat mdoc ke permintaan Anda, sebagaimana nonce dan audience mengikat SD-JWT VC.

Artikel perbandingan SD-JWT VC vs mdoc kami membahas kapan masing-masing format cocok digunakan.

Tambahan dari profil HAIP bagi verifikator EUDI

High Assurance Interoperability Profile (HAIP) mempersempit opsi OpenID4VP. ARF sudah mewajibkannya untuk penerbitan, dengan menyatakan bahwa penggunaannya "diperlukan untuk memastikan interoperabilitas".^[3] Untuk presentasi, CIR 2026/1731 menetapkan "profil OpenID4VC-HAIP" dan "profil ISO/IEC-mdoc".^[5]

Sertifikat registrasi "menjelaskan tujuan penggunaan oleh pihak pengandal dan menunjukkan atribut" yang didaftarkannya, dan regulasi registrasi berlaku mulai 24 Desember 2026.^[6] Tanggal 11 Agustus 2028 hanya mencakup pemeriksaan sertifikat tersebut di sisi dompet, bukan registrasi.^[5] Jerman merangkumnya: sebuah organisasi "menerima sertifikat akses dan registrasi untuk organisasi dan kasus penggunaan".^[12] Panduan pihak pengandal Dompet EUDI kami membahas registrasi secara lengkap.

Kesalahan umum saat membangun verifikator OpenID4VP

Dompet ini juga bersifat sukarela. Akses "tidak boleh dengan cara apa pun dibatasi atau dibuat merugikan" bagi orang yang tidak menggunakannya, sehingga verifikator Anda berdampingan dengan jalur lain.^[4]

Sumber daya pengujian

Mulailah dengan perangkat lunak referensi dan uji kesesuaian sebelum Anda menguji terhadap dompet nasional.

• Jalankan uji kesesuaian di conformance.eudi.dev.^[3]
• Baca dokumentasi implementasi referensi di docs.eudi.dev. Isinya adalah dokumentasi, bukan pengujian.^[3]
• Pelajari verifikator demo milik Bank Nasional Moldova beserta kode sumbernya.^[13]
• Periksa draf Digital Credentials API sebelum mengandalkan jalur peramban.^[9]

Untuk tanggal yang mendasari rencana pengujian Anda, lihat tenggat Dompet EUDI untuk 2026 dan 2027.

Cara Didit membantu verifikasi Dompet EUDI

Penerimaan Dompet EUDI segera hadir di Didit. Fitur ini ada dalam peta jalan kami, selaras dengan linimasa Dompet EUDI, dalam alur kerja yang sama dengan yang Anda gunakan saat ini. Sementara itu, Anda sudah dapat memverifikasi orang dari jarak jauh sekarang.

• Lima eID nasional sudah berjalan di Didit saat ini melalui dompet ID digital: MitID, BankID Sweden, Finnish Trust Network, Smart-ID, dan Mobile-ID. Lihat verifikasi eID.
• Jika seseorang tidak memiliki eID, alurnya beralih ke verifikasi dokumen dengan pembacaan cip NFC, liveness, dan pencocokan wajah, yang dikonfigurasi per negara. Satu pemeriksaan KYC lengkap berbiaya $0.33.
• Penyaringan AML berjalan dalam alur yang sama dengan biaya $0.20.

Kewajiban Anda sebagai pihak pengandal tetap ada pada Anda. Dokumentasi dompet menunjukkan cara eID diaktifkan per negara.

Pertanyaan yang sering diajukan

Sumber

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, Spesifikasi Final.
2. Spesifikasi Final OpenID for Verifiable Presentations 1.0 Disetujui, OpenID Foundation, 10 Juli 2025.
3. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet di GitHub, rilis 23 Juli 2026.
4. Peraturan (EU) 2024/1183 (eIDAS 2), EUR-Lex, Jurnal Resmi tanggal 30 April 2024.
5. Peraturan Pelaksanaan Komisi (EU) 2026/1731, EUR-Lex, Jurnal Resmi tanggal 22 Juli 2026.
6. Peraturan Pelaksanaan Komisi (EU) 2025/848 tentang pendaftaran pihak pengandal dompet, EUR-Lex, Jurnal Resmi tanggal 7 Mei 2025.
7. Peraturan Pelaksanaan Komisi (EU) 2024/2977 tentang data identifikasi orang, EUR-Lex, Jurnal Resmi tanggal 4 Desember 2024.
8. ISO/IEC 18013-7, halaman standar ISO.
9. Digital Credentials, draf W3C.
10. Digital Credentials API telah dirilis, Chrome for Developers.
11. Panduan pengembang EVO Wallet, Pemerintah Moldova, egov4dev.
12. FAQ Dompet EUDI, eudi-wallet.gov.de.
13. Verifikator demo BNM, Pemerintah Moldova, egov4dev.

OpenID4VP adalah bagian Dompet EUDI yang paling sering ditangani pengembang, dan sudah cukup stabil untuk dijadikan dasar pengembangan. Lihat pendekatan Didit terhadap penerimaan dompet di halaman solusi Dompet EUDI, dan gambaran yang lebih luas dalam ikhtisar eIDAS 2 kami.