คำถามที่พบบ่อยเกี่ยวกับข้อมูลประจำตัวและข้อมูลเข้าสู่ระบบดิจิทัล

หน้านี้จะตอบคำถามที่พบบ่อยเกี่ยวกับการผสานรวมกับ Google Wallet สำหรับบัตรประจำตัวและข้อมูลรับรองดิจิทัล

เริ่มต้นใช้งาน

ถาม: กระบวนการทีละขั้นตอนสำหรับพาร์ทเนอร์ใหม่ในการเริ่มต้นใช้งานในฐานะผู้ให้บริการที่เชื่อถือได้ (RP) คืออะไร

ตอบ: โปรดดูขั้นตอนที่การยอมรับบัตรประจำตัวจาก Wallet ทางออนไลน์

ถาม: โดยปกติแล้วกระบวนการเริ่มต้นใช้งาน RP จะใช้เวลานานเท่าใด

ตอบ: โดยปกติแล้ว การเริ่มต้นใช้งานควรใช้เวลา 3-5 วันทำการ

ถาม: เราจะติดตามสถานะการสมัคร Relying Party (RP) หลังจากส่งแล้วได้อย่างไร

ตอบ: หากไม่ได้รับการติดต่อกลับหลังจากผ่านไป 5 วัน โปรดติดต่อทีมสนับสนุนของเราที่ wallet-identity-rp-support@google.com

คำถาม: เราจะดูแบบฟอร์มการเริ่มต้นใช้งาน RP และเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์อย่างเป็นทางการได้ที่ไหน

คำตอบ:

ถาม: ระบบจะนำข้อมูลที่เราให้ (เช่น ชื่อผลิตภัณฑ์และโลโก้) ไปใช้ในประสบการณ์การใช้งานผลิตภัณฑ์อย่างไร

ตอบ: ชื่อและโลโก้ผลิตภัณฑ์จะแสดงในหน้าจอขอความยินยอมที่ผู้ใช้เห็นเพื่อช่วยให้ผู้ใช้ทราบว่าผู้ให้บริการรายใดกำลังขอรหัสประจำตัวดิจิทัลของผู้ใช้ นอกจากนี้ URL และลิงก์นโยบายอาจแสดงในประสบการณ์การใช้งานผลิตภัณฑ์ด้วย

ถาม: เราต้องลงนามในข้อกำหนดในการให้บริการไหมหากมีแผนที่จะใช้สภาพแวดล้อมแซนด์บ็อกซ์เพื่อการพัฒนาและการทดสอบเท่านั้น

ตอบ: ไม่ การยอมรับข้อกำหนดในการให้บริการไม่ใช่ขั้นตอนที่จำเป็นสำหรับการทดสอบ

ถาม: เราจะดูการใช้งานอ้างอิง โค้ดตัวอย่าง หรือแอปพลิเคชันเดโมเพื่อเริ่มต้นใช้งานได้จากที่ใด

คำตอบ:

ผู้รับจดทะเบียนผู้ตรวจสอบ

ถาม: ผู้รับจดทะเบียนที่ยืนยันคืออะไรและทำงานอย่างไร

ตอบ: ผู้รับจดทะเบียนโปรแกรมตรวจสอบทำหน้าที่เป็นผู้ออกใบรับรองที่เริ่มต้นใช้งานไคลเอ็นต์ดาวน์สตรีม (RP ปลายทาง) โดย RP ปลายทางจะไม่โต้ตอบกับ Google Wallet โดยตรง

ถาม: กระบวนการเริ่มต้นใช้งานสำหรับผู้รับจดทะเบียนที่ยืนยันตัวตนและลูกค้าปลายทางของตนมีอะไรบ้าง

ตอบ: โปรดดูขั้นตอนที่คู่มือผู้รับจดทะเบียนที่ยืนยันตัวตน

ถาม: ฟีเจอร์นี้แตกต่างจากการผสานรวม RP โดยตรงอย่างไร

ตอบ: Verifier Registrar จะจัดการความสัมพันธ์ที่เชื่อถือได้สำหรับลูกค้าและจัดการการผสานรวมกับ Google Wallet ในนามของลูกค้า ในขณะที่ RP โดยตรงจะจัดการการกำหนดค่าของตนเองกับ Google

ถาม: ใน Verifier Registrar ใครจะได้รับอนุญาตในรายการการกำหนดค่าของ Google: Verifier Registrar, RP ปลายทาง หรือทั้ง 2 อย่าง

ตอบ: Google จะเพิ่มใบรับรอง CA รูทของ Verifier Registrar ลงในรายการที่อนุญาต จากนั้นผู้รับจดทะเบียนที่ยืนยันจะออกใบรับรอง Leaf ใหม่สำหรับแต่ละ RP ปลายทางที่อยู่ดาวน์สตรีม

คำถาม: โฟลว์ข้อมูลระหว่าง RP ปลายทาง, ผู้รับจดทะเบียนที่ยืนยัน และ Google Wallet เป็นอย่างไร

ตอบ: ผู้รับจดทะเบียนผู้ยืนยันจะส่งคำขอ API ไปยัง Google Wallet สำหรับ End RP Google Wallet จะส่งข้อมูลประจำตัวที่เข้ารหัสกลับไปยังผู้รับจดทะเบียนผู้ตรวจสอบ ซึ่งจะประมวลผลข้อมูลดังกล่าวและส่งสัญญาณสุดท้ายไปยัง RP ปลายทาง

ตอบ: ไม่ได้ ผู้รับจดทะเบียนที่ยืนยันแล้วสามารถเลือกที่จะไม่แสดงรายละเอียดของตนได้

ถาม: ประเภทคีย์และเส้นโค้งที่อนุญาตสำหรับ CA หลักและใบรับรอง RP มีอะไรบ้าง

ตอบ: ควรสร้างใบรับรองโดยใช้ P-256 / ECDSA

ถาม: เราใช้ใบรับรองผู้ลงนามระดับกลางระหว่างใบรับรอง CA รูทและใบรับรอง RP ได้ไหม

ตอบ: ใช่ คุณสามารถจัดเก็บใบรับรองรูทที่มีอายุยาวนาน (เช่น ใน HSM) ได้อย่างปลอดภัยเพื่อลงนามในใบรับรองระดับกลางในการปฏิบัติงานที่ไม่บ่อยนัก จากนั้นจะใช้ใบรับรองระดับกลางเหล่านั้นเพื่อลงนามในใบรับรองแบบลีฟของ RP ปลายทางได้ ซึ่งจะช่วยให้หมุนเวียนได้ง่ายขึ้นในกรณีที่มีการละเมิดโดยไม่ส่งผลกระทบต่อรูท

คำถาม: ใบรับรองต้องมีอายุการใช้งานเท่าใด

คำตอบ: อายุการใช้งาน 10 ปีเป็นสิ่งที่ยอมรับได้สำหรับใบรับรอง CA รูท โดยทั่วไปแล้ว ใบรับรองแบบ Leaf ของ End-RP ควรมีกำหนดเวลาต่ออายุประมาณ 1 ปีเพื่อให้หมุนเวียนได้อย่างมีประสิทธิภาพในกรณีที่เกิดปัญหา

ถาม: เราต้องจัดการใบรับรองแบบลีฟแยกต่างหากสำหรับลูกค้า Relying Party (RP) แต่ละรายไหม

ตอบ: ใช่ ในช่วงเปิดตัวแรกเริ่ม ผู้รวบรวมต้องจัดการใบรับรองแยกต่างหากสำหรับ RP แต่ละรายการที่ดาวน์สตรีม ซึ่งจะช่วยให้กำหนดค่าการแสดงผลต่อ RP และติดตามการละเมิดได้อย่างถูกต้อง แม้ว่าการดำเนินการนี้จะเพิ่มค่าใช้จ่ายในการดำเนินงานในวงกว้าง แต่เราตั้งใจที่จะกลับมาพิจารณาทางเลือกอื่นๆ ที่เป็นไปได้ (เช่น การใช้แฮชข้อมูลเมตาของ RP) หลังจากการเปิดตัวครั้งแรก

ถาม: พาร์ทเนอร์ได้รับอนุญาตให้มีใบรับรองที่ใช้งานอยู่หลายใบพร้อมกันไหม

ตอบ: ได้ การกำหนดค่ารองรับใบรับรองที่ใช้งานอยู่จำนวนเท่าใดก็ได้ต่อ RP หรือผู้รวบรวม ซึ่งมีประโยชน์สำหรับพาร์ทเนอร์ที่ดำเนินงานภายใต้ชื่อธุรกิจต่างๆ

คำถาม: Distinguished Name (Subject) ควรมีรูปแบบอย่างไร

ตอบ: ชื่อที่โดดเด่นต้องไม่ซ้ำกันทั่วโลกต่อพาร์ทเนอร์ 1 ราย ซึ่งเป็นตัวระบุแบบคงที่ที่ Google ใช้เพื่อตรวจสอบคำขอจากพาร์ทเนอร์ที่เข้ามาและสร้างความน่าเชื่อถือในระบบนิเวศ

ถาม: การเชื่อมโยงโดเมนทำงานอย่างไร ต้องฝังต้นทางไว้ในใบรับรองไหม

ตอบ: ไม่จำเป็นต้องฝังโดเมนไว้ในใบรับรองโดยตรง แต่จะดำเนินการยืนยันโดเมนโดยใช้พารามิเตอร์แหล่งที่มาที่คาดไว้ในการเรียก API แทน นอกจากนี้ คุณยังเชื่อมโยงหลายโดเมนกับใบรับรองเดียวได้อย่างราบรื่น สำหรับคำขอที่ไม่ได้ลงนาม ระบบจะดำเนินการเชื่อมโยงโดยใช้ชื่อแพ็กเกจโดเมนหรือแพ็กเกจแอปพร้อมกับลายนิ้วมือ

ถาม: สามารถละเว้นรายละเอียดของผู้รวบรวมจาก UI การยืนยันเพื่อประสบการณ์การใช้งานแบบไวท์เลเบลได้ไหม

ตอบ: ได้ ข้อมูลผู้รวบรวม (เช่น ชื่อ โลโก้ URL และนโยบายความเป็นส่วนตัว) เป็นข้อมูลที่ไม่บังคับในข้อมูลเมตาของผู้ยืนยัน ซึ่งจะช่วยให้โซลูชันเป็นแบบไวท์เลเบลอย่างเต็มรูปแบบ โดยจะแสดงเฉพาะรายละเอียดของ RP ปลายทางต่อผู้ใช้

ถาม: เราต้องระบุข้อมูลใดบ้างเพื่อเริ่มการทดสอบในสภาพแวดล้อม Sandbox

ตอบ: ในแง่เทคนิค คุณเพียงแค่ต้องระบุใบรับรองรูทของ Sandbox Sandbox ออกแบบมาให้จำลองสภาพแวดล้อมที่ใช้งานจริงอย่างแม่นยำ

ถาม: กระบวนการเริ่มต้นใช้งานสำหรับผู้รับจดทะเบียนที่ยืนยัน (ผู้รวบรวม) แตกต่างจาก RP โดยตรงอย่างไร

ตอบ: ผู้รวบรวมข้อมูลจะผ่านกระบวนการที่ปรับเปลี่ยนเล็กน้อย หลังจากยอมรับข้อกำหนดในการให้บริการสำหรับผู้รับจดทะเบียนที่ได้รับการยืนยันโดยเฉพาะแล้ว การรับข้อมูลจะแบ่งออกเป็น 2 ส่วน ได้แก่ แบบฟอร์มหลักเพื่อกำหนดสถานะของคุณเป็นผู้รับจดทะเบียนที่ได้รับการยืนยัน ตามด้วยแบบฟอร์มที่ปรับปรุงแล้วซึ่งจำเป็นสำหรับ RP แต่ละรายที่คุณเริ่มต้นใช้งาน โดยปกติการส่ง RP แต่ละครั้งจะต้องมีการบันทึกวิดีโอการผสานรวม และกระบวนการตรวจสอบมักจะใช้เวลา 2-3 วันทำการ

คำถาม: เราจะเริ่มต้นใช้งานลูกค้าที่ต้องการทำหน้าที่เป็นตัวกลางหรือขายต่อบริการยืนยันให้กับนิติบุคคลอื่นๆ ได้ไหม

ตอบ: ไม่ โมเดลปัจจุบันของ Google และความต้องการคือการทำงานร่วมกับผู้รับจดทะเบียนที่ยืนยันแล้ว (ผู้รวบรวม) และ RP ปลายทางโดยตรงของตนเอง แทนที่จะสนับสนุนโมเดลตัวแทนจำหน่ายที่ซ้อนกันหรือโมเดลตัวกลาง

การผสานรวมทางเทคนิคและ API

ถาม: โปรโตคอลพื้นฐานสำหรับคำขอคืออะไร รองรับเวอร์ชันใดบ้าง

ตอบ: โปรโตคอลหลักคือ OpenID สำหรับการนำเสนอที่ตรวจสอบได้ (OpenID4VP) เวอร์ชัน 1.0

ถาม: Google รองรับภาคผนวก ISO 18013-7 ใดบ้าง (เช่น ภาคผนวก B, C, D) สำหรับการนำเสนอ mDL

ตอบ: Google รองรับภาคผนวก ง. [ปัจจุบันอยู่ในฉบับร่าง] (OpenID4VP โดยใช้ DC API)

คำถาม: เราจะจัดโครงสร้างคำขอ API อย่างถูกต้องเพื่อขอข้อมูลเข้าสู่ระบบหลายรายการในการนำเสนอผู้ใช้ครั้งเดียวได้อย่างไร

ตอบ: คุณควรร้องขอข้อมูลเข้าสู่ระบบทั้ง 2 ประเภทภายในdcqlออบเจ็กต์การค้นหาเดียวในคำขอ JSON เดียวกัน

ถาม: API อนุญาตให้ขอข้อมูลเข้าสู่ระบบทั่วไปโดยไม่ต้องระบุประเภทข้อมูลเข้าสู่ระบบที่เป็นไปได้ทั้งหมดไหม

คำตอบ: ไม่

ถาม: API จัดการการยืนยันอายุอย่างไร เราขอวันที่เกิดที่แน่นอนได้ไหม หรือขอได้แค่สัญญาณ "อายุมากกว่า X ปี"

ตอบ: รองรับทั้ง 2 แบบ คุณขอ birth_date, age_in_years หรือสัญญาณ "มากกว่า X" ที่รักษาความเป็นส่วนตัวได้ นอกจากนี้ คุณยังใช้การพิสูจน์แบบไม่เปิดเผยข้อมูล (ZKP) สำหรับสัญญาณจริง/เท็จได้ด้วย

คำถาม: ข้อกำหนดสำหรับโครงสร้างพื้นฐาน PKI ของเรามีอะไรบ้าง

ตอบ: RP ต้องมี PKI เพื่อลงนามในคำขอ ผู้รับจดทะเบียนที่ยืนยันตัวตนจะทำหน้าที่เป็น CA ของตนเอง

ถาม: เราใช้ใบรับรองที่มีอยู่ของเราเองได้ไหม หรือต้องรับใบรับรองใหม่ที่ Google ลงนาม

คำตอบ: RP ต้องมีใบรับรองใหม่ที่ลงนามโดย Google หรือผู้รับจดทะเบียนที่ยืนยัน สำหรับผู้รับจดทะเบียนที่ยืนยันตัวตน Google จะเชื่อถือใบรับรองรูทของคุณหากคุณทำตามขั้นตอน "การสร้างความน่าเชื่อถือ" ในเอกสารประกอบ

ตอบ: ควรสร้างคำขอทั้งหมดฝั่งเซิร์ฟเวอร์ ใน Android ให้ใช้ Credman API ส่วนในเว็บให้ใช้ Digital Credentials (DC) API

คำถาม: นักพัฒนาแอปมีเครื่องมือแก้ไขข้อบกพร่อง การบันทึก และความสามารถในการสังเกตอะไรบ้าง

คำตอบ: พาร์ทเนอร์สามารถใช้อีเมลแทนของทีมสนับสนุนwallet-identity-rp-support@google.com เราไม่ได้จัดหาเครื่องมือบันทึกหรือเครื่องมือสังเกตการณ์ที่เฉพาะเจาะจง

ข้อมูลเข้าสู่ระบบและข้อมูล

คำถาม: ประเทศและภูมิภาคใดบ้างที่รองรับบัตรประจำตัวดิจิทัล ผู้ออกบัตร และข้อมูลเข้าสู่ระบบ

ตอบ: ดูภูมิภาคที่รองรับได้ที่ผู้ออกใบรับรองที่รองรับ

ถาม: คุณวางแผนที่จะรองรับข้อมูลเข้าสู่ระบบจากประเทศหรือภูมิภาคใหม่ๆ เมื่อใด

ตอบ: เรากำลังเพิ่มภูมิภาคใหม่ๆ อย่างต่อเนื่อง โปรดดูข้อมูลอัปเดตในหน้าผู้ออกบัตรที่รองรับ

ถาม: เมื่อผู้ออกบัตรอัปเดตข้อมูลประจำตัว ผู้ใช้ปลายทางจะได้รับการแจ้งเตือนไหม

ตอบ: ได้ ระบบจะแจ้งให้ผู้ใช้ทราบและจะใช้การอัปเดตโดยอัตโนมัติ

ถาม: Google จัดเก็บข้อมูลเข้าสู่ระบบใดบ้าง (หากมี) ไว้ในเซิร์ฟเวอร์ โดยเฉพาะในบริบทของ GDPR

ตอบ: Google ไม่ได้บันทึกข้อมูลที่เกี่ยวข้องกับข้อมูลเข้าสู่ระบบไว้ในเซิร์ฟเวอร์ แต่จะจัดเก็บไว้ในอุปกรณ์ของผู้ใช้ในเครื่องอย่างปลอดภัย

การทดสอบและสภาพแวดล้อม

ถาม: เราจะเข้าถึงสภาพแวดล้อมแซนด์บ็อกซ์เพื่อทดสอบขั้นตอนการทำงานแบบครบวงจรได้อย่างไร

ตอบ: แซนด์บ็อกซ์เปิดอยู่ที่โหมดแซนด์บ็อกซ์

คำถาม: พาร์ทเนอร์ที่ไม่ได้อยู่ในภูมิภาคที่เปิดตัวอย่างเป็นทางการต้องดำเนินการอย่างไรจึงจะได้รับการเพิ่มลงในรายการที่อนุญาตสำหรับการทดสอบ

ตอบ: ส่งอีเมลรหัส Gmail ของกระเป๋าเงินทดสอบไปที่ wallet-identity-rp-support@google.com

ถาม: กระบวนการในการเปิดใช้เว็บไซต์หรือแอปทดสอบเพื่อวัตถุประสงค์ในการสาธิต โดยอนุญาตให้ทุกคนที่มีข้อมูลเข้าสู่ระบบเวอร์ชันที่ใช้งานจริงนำเสนอคืออะไร

ตอบ: พาร์ทเนอร์ต้องเริ่มต้นใช้งาน RP มาตรฐานให้เสร็จสมบูรณ์ ซึ่งรวมถึงการสาธิตวิดีโอใน Sandbox

ประสบการณ์ของผู้ใช้ (UX)

ถาม: ประสบการณ์ของผู้ใช้จะเป็นอย่างไรหากผู้ใช้ไม่มีบัตรประจำตัวดิจิทัลหรือไม่ได้ติดตั้งแอป Google Wallet เมื่อเริ่มขั้นตอนการยืนยัน

ตอบ: ระบบจะนำผู้ใช้ที่ไม่มีแอปไปยัง Play Store ผู้ที่ไม่มีบัตรประจำตัวสามารถสร้างบัตรประจำตัวในขั้นตอนการสมัครโดยใช้ UI แบบครึ่งหน้าจอ

ถาม: เราจะตรวจหาโดยอัตโนมัติได้ไหมว่าผู้ใช้มีบัตรประจำตัวดิจิทัลใน Wallet หรือไม่ก่อนที่จะแสดงตัวเลือกการยืนยัน

ตอบ: ไม่ได้ API ต้องเรียกใช้โดยผู้ใช้เพื่อปกป้องความเป็นส่วนตัว

ถาม: เรากำหนดให้ผู้ใช้ปลดล็อกอุปกรณ์ด้วยไบโอเมตริกก่อนแสดงข้อมูลเข้าสู่ระบบได้ไหม

ตอบ: โดยค่าเริ่มต้น ระบบกำหนดให้ต้องมีการตรวจสอบสิทธิ์ผู้ใช้ (ไบโอเมตริก, PIN หรือรูปแบบ) และปิดใช้ไม่ได้

ตอบ: ไม่ Google Wallet จะจัดเรียงบัตรตามตัวอักษร

ความปลอดภัยและการปฏิบัติตามข้อกำหนด

ถาม: กรณีการใช้งานของเราเกี่ยวข้องกับการแชร์ข้อมูลผู้ใช้กับบุคคลที่สามอีกครั้ง การกระทำดังกล่าวได้รับอนุญาตภายใต้ข้อกำหนดในการให้บริการหรือไม่

ตอบ: ได้ อาจมีข้อจำกัด โปรดดูรายละเอียดเพิ่มเติมในข้อกำหนดในการให้บริการ

คำถาม: มีเอกสารใดบ้างที่เกี่ยวข้องกับความปลอดภัย ความน่าเชื่อถือ และการเข้าถึงโซลูชันข้อมูลประจำตัวดิจิทัลเพื่อวัตถุประสงค์ในการปฏิบัติตามข้อกำหนด

ตอบ: พาร์ทเนอร์สามารถอ้างอิงรีวิวด้านความปลอดภัยของ Trail of Bits ได้

ฟีเจอร์ขั้นสูงและแผนกลยุทธ์

ถาม: ความสามารถของ Zero-Knowledge Proof (ZKP) สำหรับการยืนยันอายุที่รักษาความเป็นส่วนตัวมีอะไรบ้าง

ตอบ: Zero-Knowledge Proof (ZKP) เป็นวิธีการเข้ารหัสลับที่ช่วยให้บุคคล (ผู้พิสูจน์) พิสูจน์ต่อผู้ยืนยันได้ว่าตนมีข้อมูลระบุตัวตนบางอย่างหรือเป็นไปตามเกณฑ์ที่เฉพาะเจาะจง (เช่น อายุมากกว่า 18 ปี มีข้อมูลรับรองที่ถูกต้อง) โดยไม่ต้องเปิดเผยข้อมูลพื้นฐานที่แท้จริง

ถาม: ระบบจัดการวงจร ZK เวอร์ชันต่างๆ อย่างไร

ตอบ: RP ต้องใช้บริการเครื่องมือตรวจสอบ ZK เพื่อขอวงจรล่าสุดที่พร้อมใช้งาน

ถาม: การแชร์และการจัดการข้อมูลเข้าสู่ระบบในอุปกรณ์หลายเครื่อง เช่น โทรศัพท์และอุปกรณ์ที่สวมใส่ได้ ทำงานอย่างไร

ตอบ: ระบบจะจัดสรรข้อมูลเข้าสู่ระบบให้กับอุปกรณ์เครื่องเดียวและไม่สามารถแชร์ได้

อื่นๆ

คำถาม: Google จัดการการเพิกถอนบัตรประจำตัวอย่างไรหากมีการเพิกถอนหนังสือเดินทาง

ตอบ: ผู้ใช้สามารถลบบัตรจากส่วนการตั้งค่าบัญชี Google ได้ และสามารถรายงานอุปกรณ์ที่สูญหายเพื่อเพิกถอนข้อมูลเข้าสู่ระบบได้

ถาม: มีการจัดการการเพิกถอน mDL อย่างไร เป็นแบบเรียลไทม์ไหม

ตอบ: ผู้ใช้สามารถทริกเกอร์หรือผู้ออก (DMV) สามารถพุชได้ โดยจะเป็นแบบเรียลไทม์หากอุปกรณ์ออนไลน์อยู่ มิเช่นนั้นออบเจ็กต์ความปลอดภัยแบบอายุสั้น (MSO) จะหมดอายุ

ถาม: นโยบายการหมุนเวียนคีย์สำหรับ RP คืออะไร

ตอบ: เราขอแนะนำให้หมุนเวียนคีย์ทุกปี

ถาม: Android เวอร์ชันขั้นต่ำที่รองรับสำหรับ Digital Credentials API คืออะไร

ตอบ: Android 9 (ระดับ API 28) ขึ้นไป

ถาม: Chrome เวอร์ชันขั้นต่ำที่รองรับ Digital Credentials API คือเวอร์ชันใด

ตอบ: Chrome เวอร์ชัน 128 ขึ้นไป

คำถาม: เบราว์เซอร์ใดบ้างที่รองรับ Digital Credentials API

ตอบ: คุณดูรายละเอียดการรองรับเบราว์เซอร์ได้ที่ https://digitalcredentials.dev/ecosystem-support

ถาม: ผู้ใช้กลุ่มใดบ้างที่จะเพิ่มบัตรประจำตัวได้เมื่อมีการเปิดตัวในประเทศใหม่

ตอบ: สิทธิ์เข้าถึงจะขึ้นอยู่กับการตั้งค่าประเทศของผู้ใช้ใน Play Store

ถาม: Digital Credentials API ใช้กับ iOS ได้ไหม

ตอบ: ได้ API ทำงานโดยใช้เบราว์เซอร์ที่รองรับ เช่น Safari อย่างไรก็ตาม Apple ไม่รองรับ OpenID4VP