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

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

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

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

คำตอบ: ทำตามคำแนะนำทีละขั้นตอนที่หัวข้อเลือกเส้นทางของคุณ

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

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

ถาม: เราจะติดตามสถานะการสมัครเป็นฝ่ายที่อาศัยเนื้อหา (RP) หลังจากส่งใบสมัครได้อย่างไร

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

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

คำตอบ:

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

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

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

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

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

คำตอบ:

ผู้รับจดทะเบียน Verifier

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

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

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

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

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

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

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

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

ถาม: ข้อมูลจะไหลระหว่าง RP ปลายทาง, ผู้รับจดทะเบียนผู้ตรวจสอบ และ Google Wallet อย่างไร

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

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

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

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

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

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

ถาม: อายุการใช้งานที่จำเป็นสำหรับใบรับรองคือเท่าใด

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

ถาม: เราจำเป็นต้องจัดการใบรับรอง Leaf แยกต่างหากสำหรับลูกค้าฝ่ายที่อาศัย (RP) แต่ละรายไหม

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

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

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

ถาม: ควรจัดรูปแบบชื่อที่จำแนกได้ (เรื่อง) อย่างไร

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

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

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

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

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

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

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

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

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

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

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

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

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

ตอบ: โปรโตคอลหลักคือ OpenID for Verifiable Presentations (OpenID4VP) เวอร์ชัน 1.0

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

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

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

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

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

คำตอบ: ไม่ได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ประสบการณ์ของผู้ใช้ (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 จะจัดการการเพิกถอน ID พาสอย่างไรหากหนังสือเดินทางถูกเพิกถอน

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

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

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

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

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

ถาม: Digital Credentials API รองรับ Android เวอร์ชันใดเป็นเวอร์ชันขั้นต่ำ

คำตอบ: 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