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 thứ ba đáng 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 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 bản triển khai tham chiếu, mã mẫu hoặc một ứng dụng minh hoạ để bắt đầu ở đâu?

A:

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

Hỏi: 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à tổ chức phát hành chứng chỉ để tham gia các ứng dụng hạ lưu (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ể cho 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: Chế độ này khác gì so với chế độ 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 họ 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 cùng 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ẽ cấp chứng chỉ lá mới cho mỗi RP cuối nguồn.

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

Đáp: Trình đăng ký của 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 Trình đăng ký xác minh. Sau đó, Trình đăng ký xác minh sẽ xử lý dữ liệu này và gửi tín hiệu cuối cùng đến RP cuối.

Đáp: Không. Người đă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ỉ gốc 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ập 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 đị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 riêng 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 sử 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. Ngoài ra, 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 ứng dụng hoặc Miền 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 cho trải nghiệm được 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: Quá trình tham gia của Người 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ể của Người xác minh, 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, 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ể tham gia quy trình xác minh cho những 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 sử dụ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" đảm bảo quyền riêng tư. Bạn cũng có thể sử dụng Bằng chứng 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 gì?

Đá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 Registrars, 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 dùng Credman API; trên web, hãy dùng Digital Credentials (DC) API.

Hỏi: Nhà phát triển có 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 wallet-identity-rp-support@google.com để liên hệ với nhóm hỗ trợ. 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 điện tử, tổ chức phát hành và thông tin đăng nhập 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 thì 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.

Hỏi: Google lưu trữ dữ liệu thông tin đăng nhập nào (nếu có) trên các máy chủ của mình, đặc biệt là trong bối cảnh GDPR?

Đáp: Google không lưu dữ liệu liên quan đến thông tin đăng nhập trên máy chủ của mình; dữ liệu này được lưu trữ cục bộ và an toàn trên thiết bị của người dùng.

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

Hỏi: Làm cách nào để truy cập vào môi trường hộp cát nhằm 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 ở khu vực được ra mắt chính thức vào danh sách cho phép để kiểm thử 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 để bật một trang web hoặc ứng dụng kiểm thử cho mục đích minh hoạ 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 ngay trong quy trình bằng giao diện người dùng nửa màn hình.

Hỏi: Chúng ta 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, API phải do người dùng gọi để bảo vệ quyền riêng tư.

Hỏi: Chúng tôi 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 lại các thẻ theo thứ tự 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ể có 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 những 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 về danh tính kỹ thuật số cho mục đích tuân thủ?

Đáp: Đối tác có thể tham khảo các bài đá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 quy trình xác minh tuổi đả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ật mã học 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ó chứng chỉ 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: Tính năng 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 thẻ giấy tờ tuỳ thân 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 xác thực.

Hỏi: Việc thu hồi mDL được xử lý như thế nào? Có phải là theo 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 (Sở Quản lý phương tiện cơ giới) gửi. Đây là 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 thay 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.