Câu hỏi thường gặp về danh tính và thông tin xác thực kỹ thuật số

Trang này giải đáp các câu hỏi thường gặp về việc tích hợp với Google Wallet cho Danh tính và thông tin xác thực kỹ thuật số.

Tham gia và bắt đầu

Hỏi: Quy trình từng bước để một đối tác mới tham gia với tư cách là Bên tin cậy (RP) là gì?

Đáp: Hãy tham khảo các bước tại: Chấp nhận giấy tờ tuỳ thân trong Wallet trực tuyến.

Hỏi: Quy trình tham gia RP thường kéo dài bao lâu?

Đáp: Thông thường, quá trình tham gia sẽ mất từ 3 đến 5 ngày làm việc.

Hỏi: Làm cách nào để theo dõi trạng thái của đơn đăng ký Bên tin cậy (RP) sau khi gửi?

Đáp: Nếu bạn không nhận được phản hồi sau 5 ngày, vui lòng liên hệ với nhóm hỗ trợ của chúng tôi trên wallet-identity-rp-support@google.com.

Hỏi: Chúng tôi có thể tìm biểu mẫu tham gia RP và tài liệu chính thức dành cho nhà phát triển ở đâu?

A:

Hỏi: Thông tin chúng tôi cung cấp (chẳng hạn như Tên sản phẩm và Logo) sẽ được sử dụng như thế nào trong trải nghiệm về sản phẩm?

Đáp: Tên và biểu trưng sản phẩm xuất hiện trên màn hình xin phép mà người dùng nhìn thấy để giúp người dùng xác định Bên tin cậy nào đang yêu cầu thẻ căn cước điện tử của họ. URL và đường liên kết đến chính sách cũng có thể xuất hiện trong trải nghiệm về sản phẩm.

Hỏi: Chúng tôi có cần ký Điều khoản dịch vụ nếu chỉ dự định sử dụng môi trường hộp cát để phát triển và thử nghiệm không?

Đáp: Không, chấp nhận Điều khoản dịch vụ không phải là bước bắt buộc để kiểm thử.

Hỏi: Chúng tôi có thể tìm thấy một cách triển khai tham chiếu, mã mẫu hoặc ứng dụng minh hoạ để bắt đầu ở đâu?

A:

Nhà đăng ký người xác minh

Hỏi: Trình đăng ký xác minh là gì và hoạt động như thế nào?

Đáp: Trình đăng ký xác minh đóng vai trò là Cơ quan cấp chứng chỉ để tham gia các khách hàng hạ nguồn (RP cuối). RP cuối không tương tác trực tiếp với Google Wallet.

Hỏi: Quy trình tham gia cụ thể đối với Nhà đăng ký xác minh và các khách hàng hạ nguồn của họ là gì?

Đáp: Hãy tham khảo các bước tại: Hướng dẫn dành cho nhà đăng ký tên miền xác minh.

Hỏi: Phương thức này khác gì so với việc tích hợp RP trực tiếp?

Đáp: Verifier Registrar quản lý mối quan hệ tin cậy cho khách hàng và thay mặt khách hàng xử lý việc tích hợp với Google Wallet, trong khi RP trực tiếp tự quản lý cấu hình của họ với Google.

Hỏi: Trong Trình đăng ký xác minh, ai được đưa vào danh sách cho phép trong cấu hình của Google: Trình đăng ký xác minh, RP cuối hay cả hai?

Đáp: Google đưa chứng chỉ CA gốc của Nhà đăng ký xác minh vào danh sách cho phép. Sau đó, Trình đăng ký xác minh sẽ phát hành các chứng chỉ lá mới cho mỗi RP cuối nguồn.

Hỏi: Dữ liệu lưu chuyển như thế nào giữa RP cuối, Trình xác minh đăng ký và Google Wallet?

Đáp: Trình đăng ký trình xác minh gửi yêu cầu API đến Google Wallet cho RP cuối. Google Wallet trả về dữ liệu thông tin xác thực đã mã hoá cho Verifier Registrar. Sau đó, Verifier Registrar xử lý dữ liệu này và gửi tín hiệu cuối cùng đến End RP.

Đáp: Không. Đơn vị đăng ký xác minh có thể chọn không hiển thị thông tin chi tiết của họ.

Hỏi: Những loại khoá và đường cong nào được phép dùng cho Chứng chỉ CA gốc và Chứng chỉ RP?

Đáp: Bạn nên tạo chứng chỉ bằng P-256 / ECDSA.

Hỏi: Chúng tôi có thể sử dụng chứng chỉ người ký trung gian giữa CA gốc và chứng chỉ lá RP không?

Đáp: Có. Bạn có thể lưu trữ an toàn một chứng chỉ gốc có thời hạn sử dụng dài (ví dụ: trong HSM) để hiếm khi ký các chứng chỉ trung gian hoạt động. Sau đó, bạn có thể dùng các chứng chỉ trung gian đó để ký các chứng chỉ lá RP cuối, giúp việc xoay vòng dễ dàng hơn trong trường hợp xảy ra vi phạm mà không ảnh hưởng đến gốc.

Hỏi: Chứng chỉ phải có thời hạn sử dụng tối thiểu là bao lâu?

Đáp: Chứng chỉ CA gốc có thời hạn 10 năm là hoàn toàn chấp nhận được. Chứng chỉ lá End-RP thường phải tuân theo tiến trình gia hạn khoảng 1 năm để đảm bảo có thể xoay vòng hiệu quả nếu có vấn đề phát sinh.

Hỏi: Chúng ta có cần quản lý một chứng chỉ lá riêng cho từng khách hàng Bên tin cậy (RP) không?

Đáp: Có. Trong giai đoạn ra mắt ban đầu, các đơn vị tổng hợp phải quản lý các chứng chỉ riêng biệt cho từng RP hạ nguồn. Điều này cho phép bạn định cấu hình chế độ hiển thị cho mỗi RP và theo dõi hành vi sai trái một cách chính xác. Mặc dù điều này làm tăng chi phí vận hành ở quy mô lớn, nhưng chúng tôi dự định xem xét lại các giải pháp thay thế tiềm năng (chẳng hạn như sử dụng hàm băm siêu dữ liệu RP) sau lần triển khai ban đầu.

Hỏi: Đối tác có được phép có nhiều chứng chỉ đang hoạt động cùng một lúc không?

Đáp: Có. Cấu hình này hỗ trợ mọi số lượng chứng chỉ đang hoạt động cho mỗi RP hoặc đơn vị tổng hợp. Điều này hữu ích cho những đối tác hoạt động dưới nhiều tên doanh nghiệp.

Hỏi: Tên phân biệt (Chủ đề) phải được định dạng như thế nào?

Đáp: Tên phân biệt phải là duy nhất trên toàn cầu cho mỗi đối tác. Đây là một giá trị nhận dạng tĩnh mà Google dùng để theo dõi các yêu cầu đến từ đối tác và đảm bảo độ tin cậy của hệ sinh thái.

Hỏi: Tính năng liên kết miền hoạt động như thế nào? Có cần nhúng nguồn gốc vào chứng chỉ không?

Đáp: Bạn không cần nhúng miền trực tiếp vào chính chứng chỉ. Thay vào đó, quá trình xác minh miền được thực hiện bằng cách sử dụng tham số nguồn gốc dự kiến trong lệnh gọi API. Hơn nữa, bạn có thể liên kết nhiều miền với một chứng chỉ duy nhất một cách liền mạch. Đối với các yêu cầu chưa ký, hoạt động liên kết được thực thi bằng cách sử dụng Tên gói miền hoặc Tên gói ứng dụng cùng với một dấu vân tay.

Hỏi: Tôi có thể bỏ qua thông tin chi tiết về đơn vị tập hợp trong giao diện người dùng xác minh để có trải nghiệm gắn nhãn riêng không?

Đáp: Có. Bạn hoàn toàn không bắt buộc phải cung cấp thông tin về đơn vị tập hợp (chẳng hạn như tên, biểu trưng, URL và chính sách quyền riêng tư) trong siêu dữ liệu của đơn vị xác minh. Điều này cho phép một giải pháp hoàn toàn có nhãn hiệu riêng, trong đó chỉ có thông tin chi tiết về RP cuối cùng được hiển thị cho người dùng.

Hỏi: Chúng tôi cần cung cấp những gì để bắt đầu kiểm thử trong môi trường Hộp cát?

Đáp: Về mặt kỹ thuật, bạn chỉ cần cung cấp Chứng chỉ gốc của Hộp cát. Hộp cát được thiết kế để phản ánh chính xác môi trường thực tế.

Hỏi: Quy trình tham gia của Người đăng ký xác minh (Người tổng hợp) khác với RP trực tiếp như thế nào?

Đáp: Các đơn vị tập hợp sẽ trải qua một quy trình có chút thay đổi. Sau khi thực hiện Điều khoản dịch vụ cụ thể dành cho Người xác minh đăng ký, quy trình tiếp nhận sẽ được chia thành hai phần: một biểu mẫu chính để xác lập trạng thái của bạn là Người xác minh đăng ký, sau đó là một biểu mẫu tinh giản bắt buộc đối với từng RP mà bạn tham gia. Mỗi lần gửi yêu cầu RP thường cần có bản ghi hình về quá trình tích hợp và quy trình xem xét thường mất từ 2 đến 3 ngày làm việc.

Hỏi: Chúng tôi có thể giới thiệu khách hàng có ý định đóng vai trò là bên trung gian hoặc bán lại dịch vụ xác minh cho các pháp nhân khác không?

Đáp: Không. Mô hình và lựa chọn hiện tại của Google là làm việc trực tiếp với các Đơn vị đăng ký xác minh (đơn vị tổng hợp) và các RP cuối trực tiếp của họ, thay vì hỗ trợ các mô hình đại lý hoặc trung gian lồng nhau.

Tích hợp kỹ thuật và API

Hỏi: Giao thức cơ bản cho các yêu cầu là gì? Những phiên bản nào được hỗ trợ?

Đáp: Giao thức chính là OpenID cho Bản trình bày có thể xác minh (OpenID4VP) phiên bản 1.0.

Hỏi: Google hỗ trợ những phụ lục nào theo tiêu chuẩn ISO 18013-7 (ví dụ: Phụ lục B, C, D) để trình bày mDL?

Đáp: Google hỗ trợ Phụ lục D [hiện đang ở bản nháp] (OpenID4VP bằng DC API).

Hỏi: Làm cách nào để chúng tôi cấu trúc đúng một yêu cầu API nhằm yêu cầu nhiều thông tin đăng nhập trong một lần trình bày cho người dùng?

Đáp: Bạn nên yêu cầu cả hai loại thông tin đăng nhập trong một đối tượng truy vấn dcql duy nhất trong cùng một yêu cầu JSON.

Hỏi: API này có cho phép yêu cầu một thông tin đăng nhập chung mà không cần liệt kê mọi loại thông tin đăng nhập có thể có không?

Đáp: Không.

Hỏi: API xử lý quy trình xác minh tuổi như thế nào? Chúng tôi có thể yêu cầu ngày sinh chính xác hay chỉ yêu cầu tín hiệu "trên X"?

Đáp: Cả hai đều được hỗ trợ. Bạn có thể yêu cầu birth_date, age_in_years hoặc tín hiệu "trên X" bảo đảm quyền riêng tư. Bạn cũng có thể sử dụng Chứng minh không tiết lộ (ZKP) cho tín hiệu đúng/sai.

Hỏi: Cơ sở hạ tầng PKI của chúng tôi cần đáp ứng những yêu cầu nào?

Đáp: RP cần có PKI để ký các yêu cầu. Verifier Registrars đóng vai trò là CA của riêng họ.

Hỏi: Chúng tôi có thể sử dụng các chứng chỉ hiện có của riêng mình hay cần phải có một chứng chỉ mới do Google ký?

Đáp: RP cần có một chứng chỉ mới do Google hoặc một Verifier Registrar ký. Đối với Verifier Registrar, Google sẽ tin tưởng Chứng chỉ gốc của bạn nếu bạn làm theo các bước "Thiết lập độ tin cậy" trong tài liệu.

Đáp: Toàn bộ yêu cầu phải được tạo phía máy chủ. Trên Android, hãy sử dụng Credman API; trên web, hãy sử dụng Digital Credentials (DC) API.

Hỏi: Nhà phát triển có thể sử dụng những công cụ gỡ lỗi, ghi nhật ký và khả năng ghi nhận nào?

Đáp: Đối tác có thể sử dụng bí danh hỗ trợ wallet-identity-rp-support@google.com. Không có công cụ ghi nhật ký hoặc công cụ quan sát cụ thể nào được cung cấp.

Thông tin đăng nhập và dữ liệu

Hỏi: Những giấy tờ tuỳ thân kỹ thuật số, tổ chức phát hành và thông tin xác thực nào được hỗ trợ theo quốc gia và khu vực?

Đáp: Bạn có thể xem các khu vực được hỗ trợ tại đây: Các tổ chức phát hành và chứng chỉ được hỗ trợ.

Hỏi: Khi nào bạn dự định hỗ trợ thông tin đăng nhập của các quốc gia hoặc khu vực mới?

Đáp: Chúng tôi đang tích cực bổ sung các khu vực mới; hãy kiểm tra trang nhà phát hành được hỗ trợ để biết thông tin cập nhật.

Hỏi: Khi tổ chức phát hành cập nhật thông tin đăng nhập, người dùng cuối có nhận được thông báo không?

Đáp: Có, người dùng sẽ nhận được thông báo và bản cập nhật sẽ được áp dụng tự động.

Thử nghiệm và môi trường

Hỏi: Làm cách nào để chúng tôi có quyền truy cập vào môi trường hộp cát để kiểm thử toàn bộ quy trình từ đầu đến cuối?

Đáp: Hộp cát đang mở ở Chế độ hộp cát.

Hỏi: Quy trình thêm đối tác không có trụ sở tại một khu vực đã ra mắt chính thức vào danh sách cho phép để thử nghiệm là gì?

Đáp: Gửi email chứa mã nhận dạng Gmail của các ví kiểm thử đến wallet-identity-rp-support@google.com.

Hỏi: Quy trình cho phép một trang web hoặc ứng dụng kiểm thử cho mục đích bản minh họa là gì, cho phép bất kỳ ai có thông tin đăng nhập phát hành công khai đều có thể trình bày thông tin đó?

Đáp: Đối tác phải hoàn tất quy trình tham gia RP tiêu chuẩn, bao gồm cả bản minh hoạ video trong môi trường thử nghiệm.

Trải nghiệm người dùng (UX)

Hỏi: Trải nghiệm người dùng sẽ như thế nào nếu người dùng không có thẻ căn cước điện tử hoặc chưa cài đặt ứng dụng Google Wallet khi họ bắt đầu quy trình xác minh?

Đáp: Những người dùng chưa cài đặt ứng dụng sẽ được chuyển hướng đến Cửa hàng Play. Những người không có thẻ căn cước có thể tạo thẻ căn cước trong quy trình bằng giao diện người dùng nửa màn hình.

Hỏi: Chúng tôi có thể phát hiện theo phương thức lập trình xem người dùng có thẻ căn cước điện tử trong Wallet hay không trước khi cho họ thấy lựa chọn xác minh không?

Đáp: Không, người dùng phải gọi API này để bảo vệ quyền riêng tư.

Hỏi: Chúng ta có thể yêu cầu người dùng mở khoá thiết bị bằng dữ liệu sinh trắc học trước khi xuất hiện thông tin xác thực không?

Đáp: Theo mặc định, bạn phải xác thực người dùng (bằng dữ liệu sinh trắc học, mã PIN hoặc hình mở khoá) và không thể tắt tính năng này.

Đáp: Không, Google Wallet sắp xếp các thẻ theo bảng chữ cái.

Bảo mật và tuân thủ

Hỏi: Trường hợp sử dụng của chúng tôi liên quan đến việc chia sẻ lại dữ liệu người dùng với bên thứ ba. Điều này có được phép theo Điều khoản dịch vụ không?

Đáp: Có, có thể áp dụng các quy định hạn chế, hãy xem điều khoản dịch vụ của chúng tôi để biết thêm thông tin chi tiết.

Hỏi: Chúng tôi có thể xem tài liệu nào về tính bảo mật, độ tin cậy và khả năng hỗ trợ tiếp cận của các giải pháp nhận dạng kỹ thuật số cho mục đích tuân thủ?

Đáp: Đối tác có thể tham khảo các đánh giá bảo mật của Trail of Bits.

Tính năng nâng cao và lộ trình

Hỏi: Zero-Knowledge Proofs (ZKP) có những khả năng gì trong việc xác minh tuổi mà vẫn đảm bảo quyền riêng tư?

Đáp: Chứng minh không tiết lộ (ZKP) là một phương pháp mã hoá cho phép một cá nhân (người chứng minh) chứng minh cho người xác minh rằng họ có một thông tin nhận dạng nhất định hoặc đáp ứng một tiêu chí cụ thể (ví dụ: trên 18 tuổi, có thông tin xác thực hợp lệ) mà không tiết lộ dữ liệu cơ bản thực tế.

Hỏi: Các phiên bản khác nhau của mạch ZK được xử lý như thế nào?

Đáp: RP phải triển khai các dịch vụ xác minh ZK để yêu cầu các mạch điện hiện có mới nhất.

Hỏi: Việc chia sẻ và quản lý thông tin đăng nhập hoạt động như thế nào trên nhiều thiết bị, chẳng hạn như điện thoại và thiết bị đeo?

Đáp: Thông tin đăng nhập được cung cấp cho một thiết bị duy nhất và không thể chia sẻ.

Khác

Hỏi: Google xử lý việc thu hồi giấy tờ tuỳ thân điện tử như thế nào nếu hộ chiếu bị thu hồi?

Đáp: Người dùng có thể xoá thẻ và vé trong phần cài đặt Tài khoản Google; người dùng có thể báo cáo thiết bị bị mất để thu hồi thông tin đăng nhập.

Hỏi: Việc thu hồi mDL được xử lý như thế nào? Có phải là thời gian thực không?

Đáp: Thông báo này có thể do người dùng kích hoạt hoặc do tổ chức phát hành (DMV) gửi. Đây là thông tin theo thời gian thực nếu thiết bị có kết nối mạng; nếu không, các đối tượng bảo mật tồn tại trong thời gian ngắn (MSO) sẽ hết hạn.

Hỏi: Chính sách xoay vòng khoá cho RP là gì?

Đáp: Bạn nên xoay vòng hằng năm.

Hỏi: Phiên bản Android tối thiểu được hỗ trợ cho Digital Credentials API là gì?

Đáp: Android 9 (cấp độ API 28) trở lên.

Hỏi: Phiên bản Chrome tối thiểu hỗ trợ Digital Credentials API là gì?

Đáp: Chrome phiên bản 128 trở lên.

Hỏi: Những trình duyệt nào hỗ trợ Digital Credentials API?

Đáp: Bạn có thể xem thông tin chi tiết về trình duyệt được hỗ trợ tại đây: https://digitalcredentials.dev/ecosystem-support

Hỏi: Những người dùng nào có thể thêm mã nhận dạng khi một quốc gia mới được ra mắt?

Đáp: Quyền truy cập phụ thuộc vào chế độ cài đặt quốc gia của người dùng trong Cửa hàng Play.

Hỏi: Digital Credentials API có hoạt động với iOS không?

Đáp: Có. API này hoạt động bằng các trình duyệt được hỗ trợ như Safari. Tuy nhiên, Apple không hỗ trợ OpenID4VP.