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

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 phụ thuộc (RP) là gì?

Đáp: Hãy làm theo hướng dẫn từng bước tại: Chọn lộ trình của bạn.

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

Đáp: Thông thường, quá trình đào tạo nhân viên mới 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 phụ thuộc (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 tại wallet-identity-rp-support@google.com.

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

A:

• Biểu mẫu tham gia: Biểu mẫu liên hệ dành cho bên xác thực danh tính của Google Wallet
• Tài liệu dành cho nhà phát triển: Tổng quan về danh tính kỹ thuật số

Hỏi: Thông tin chúng tôi cung cấp (như Tên sản phẩm và Biểu trưng) 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 dành cho người dùng để giúp người dùng xác định Bên phụ thuộc nào đang yêu cầu giấy tờ tuỳ thân kỹ thuật số 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 sản phẩm.

Hỏi: Chúng tôi có cần ký Điều khoản dịch vụ nếu chỉ đị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, việc chấp nhận Điều khoản dịch vụ không phải là bước bắt buộc để thử nghiệm.

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

A:

• Kho lưu trữ GitHub: Triển khai tham chiếu danh tính.
• Trang web thử nghiệm: verifier.multipaz.org

Hỏi: Verifier Registrar là gì và hoạt động như thế nào?

Đáp: Cơ quan đăng ký xác minh đóng vai trò là Tổ chức phát hành chứng chỉ, giúp các ứng dụng khách hạ nguồn (RP cuối) tham gia. Bên phụ thuộc 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ể dành cho Nhà đăng ký xác minh và khách hàng cấp dưới của họ là gì?

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

Hỏi: Phương thức này khác với việc tích hợp trực tiếp với bên tin cậy như thế nào?

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

Hỏi: Trong Verifier Registrar, ai được đưa vào danh sách cho phép trong cấu hình của Google: Verifier Registrar, 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 đó, Nhà đăng ký xác minh sẽ cấp chứng chỉ lá mới cho mỗi RP cuối hạ nguồn.

Hỏi: Dữ liệu di chuyển như thế nào giữa bên nhận uỷ thác cuối, Cơ quan đăng ký xác minh và Google Wallet?

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

Hỏi: Đối với các giải pháp nhãn trắng, có bắt buộc phải hiển thị tên của Đơn vị đăng ký xác minh trong quy trình lấy sự đồng ý của người dùng không, hay chỉ cần hiển thị tên của Bên phụ thuộc cuối?

Đáp: Không. Cơ quan đă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: Các loại khoá và đường cong được phép sử dụng cho CA gốc và Chứng chỉ RP là gì?

Đá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ỉ của bên ký trung gian giữa CA gốc và chứng chỉ lá của bên tin cậy không?

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

Hỏi: Thời hạn bắt buộc của chứng chỉ là bao lâu?

Đáp: Thời hạn 10 năm là hoàn toàn chấp nhận được đối với chứng chỉ CA gốc. Chứng chỉ lá của RP cuối thường phải tuân theo thời gian 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 tôi có cần quản lý một chứng chỉ lá riêng biệt cho từng khách hàng là Bên Relying Party (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ý chứng chỉ riêng cho từng RP hạ nguồn. Điều này cho phép cấu hình hiển thị theo từng bên bị tin cậy và theo dõi hành vi sai trái một cách chính xác. Mặc dù việc này làm tăng mức hao tổn hoạt động trên 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 của bên tin cậy) sau khi triển khai lần đầu.

Hỏi: Đối tác có được phép có nhiều chứng chỉ còn hiệu lực cùng một lúc không?

Đáp: Có, cấu hình này hỗ trợ số lượng chứng chỉ đang hoạt động không giới hạn cho mỗi RP hoặc đơn vị tổng hợp, điều này rất 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 riêng biệt (Chủ thể) 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 hệ thống cho mỗi đối tác. Đây là 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 sự tin cậy trong 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 phải nhúng trực tiếp miền vào chứng chỉ. Thay vào đó, quy 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 liền mạch nhiều miền với một chứng chỉ. Đối với các yêu cầu chưa ký, việc liên kết được thực hiện bằng cách sử dụng Tên miền hoặc Tên gói ứng dụng cùng với vân tay số.

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

Đáp: Có, thông tin về đơn vị tổng hợp (chẳng hạn như tên, biểu trưng, URL và chính sách quyền riêng tư) là hoàn toàn không bắt buộc trong siêu dữ liệu của trình xác minh. Điều này cho phép một giải pháp hoàn toàn không có nhãn hiệu, trong đó chỉ có thông tin chi tiết về RP cuối đượ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 thử nghiệm 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 làm quen của Nhà đăng ký xác minh (Nhà tổng hợp) khác với quy trình của Bên phụ thuộc trực tiếp như thế nào?

Đáp: Các đơn vị tổng hợp sẽ trải qua một quy trình được điều chỉnh đôi chút. Sau khi thực thi Điều khoản dịch vụ cụ thể của Nhà đăng ký xác minh, quy trình tiếp nhận sẽ được chia thành hai phần: biểu mẫu chính để thiết lập trạng thái của bạn là Nhà đăng ký xác minh, sau đó là biểu mẫu đơn giản cần thiết cho mỗi RP mà bạn tham gia. Mỗi lần gửi RP thường yêu cầu một bản ghi video 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 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 ưu tiên hiện tại của Google là làm việc trực tiếp với các Nhà đăng ký xác minh (đơn vị tổng hợp) và các Bên tin cậy (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.

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 Giấy tờ tuỳ thân có thể xác minh (OpenID4VP) phiên bản 1.0.

Hỏi: Google hỗ trợ những phụ lục nào của ISO 18013-7 (ví dụ: Phụ lục B, C, D) cho việc trình bày mDL?

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

Hỏi: Làm cách nào để cấu trúc chính xác một yêu cầu API nhằm yêu cầu nhiều thông tin xác thực trong một bản trình bày của người dùng?

Đáp: Bạn nên yêu cầu cả hai loại thông tin xác thực 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 có cho phép yêu cầu thông tin xác thực chung mà không cần liệt kê mọi loại thông tin xác thực 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 tuổi"?

Đá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ộ tri thức (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ý yêu cầu. Nhà đăng ký xác minh đóng vai trò là CA của riêng họ.

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

Đáp: RP cần có chứng chỉ mới do Google hoặc Cơ quan đăng ký xác minh ký. Đối với Nhà đăng ký xác minh, 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 mối quan hệ tin cậy" trong tài liệu.

Hỏi: Chiến lược tích hợp được đề xuất cho web so với ứng dụng Android là gì?

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

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 email hỗ trợ wallet-identity-rp-support@google.com. Không có công cụ ghi nhật ký hoặc khả năng ghi nhận cụ thể nào được cung cấp.

Hỏi: Những giấy tờ tuỳ thân điện tử, 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: 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 các bạn dự định hỗ trợ giấy tờ tuỳ thân 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 xem trang các công ty phát hành thẻ được hỗ trợ để biết thông tin cập nhật.

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

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

Hỏi: Làm cách nào để 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 mở tại: Chế độ hộp cát.

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

Đáp: Gửi email chứa địa chỉ Gmail của các ví thử nghiệm đến wallet-identity-rp-support@google.com.

Hỏi: Quy trình bật một trang web hoặc ứng dụng thử nghiệm cho mục đích minh hoạ, cho phép bất kỳ ai có thông tin xác thực chính thức đều có thể trình bày là gì?

Đáp: Đối tác phải hoàn tất quy trình làm quen tiêu chuẩn của RP, bao gồm cả video minh hoạ trong hộp cát.

Hỏi: Trải nghiệm của người dùng sẽ như thế nào nếu họ không có giấy tờ tuỳ thân kỹ thuật số hoặc chưa cài đặt ứng dụng Google Wallet khi bắt đầu quy trình xác minh?

Đáp: 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 chưa có giấy tờ tuỳ thân có thể tạo giấy tờ tuỳ thân 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 cách lập trình xem người dùng có giấy tờ tuỳ thân kỹ thuật số 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 trình bày 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 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.

Hỏi: Tôi có thể tuỳ chỉnh thứ tự của các thuộc tính được yêu cầu trên màn hình xin phép người dùng không?

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

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 khoản dịch vụ có cho phép việc này 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.

Hỏi: Có 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 danh tính kỹ thuật số để phục vụ mục đích tuân thủ của chúng tôi không?

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

Hỏi: Bằng chứng không tri thức (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: Bằng chứng không tri thức (ZKP) là một phương pháp mật mã hoá cho phép một cá nhân (người chứng minh) chứng minh với người xác minh rằng họ sở hữu 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 cần tiết lộ dữ liệu 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 dịch vụ xác minh ZK để yêu cầu các mạch mới nhất hiện có.

Hỏi: Việc chia sẻ và quản lý thông tin xác thực 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 cấp cho một thiết bị duy nhất và không thể chia sẻ.

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; 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 theo thời gian thực không?

Đáp: Người dùng có thể kích hoạt hoặc tổ chức phát hành (DMV) có thể gửi thông báo. Dữ liệu này được thu thập 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 ngắn hạ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 thay đổi 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à phiên bản nào?

Đá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ề khả năng hỗ trợ của trình duyệt tại đây: https://digitalcredentials.dev/ecosystem-support

Hỏi: Những người dùng nào sẽ có thể thêm giấy tờ tuỳ thân khi một quốc gia mới được ra mắt?

Đáp: Quyền truy cập được cấp dựa trên 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 trên các trình duyệt được hỗ trợ như Safari. Tuy nhiên, Apple không hỗ trợ OpenID4VP.