Cảnh Sát, Quầy Cho Thuê Xe, Nhà Tuyển Dụng, Công Ty Bảo Hiểm: Tại Sao Họ Không Được Thấy Cùng Một Dữ Liệu

Sai lầm thiết kế lớn nhất trong một Giấy Phép Lái Xe Quốc Tế (IDP) tương lai là coi mọi bên xác minh đều giống nhau. Một cảnh sát viên, một quầy cho thuê xe, một nhà tuyển dụng và một công ty bảo hiểm không đặt ra cùng một câu hỏi — vì vậy họ không nên nhận được cùng một câu trả lời.

Một tài xế. Một quyền lái xe duy nhất. Một ví điện tử. Nhưng bốn bên xác minh rất khác nhau:

• Một cảnh sát viên tại hiện trường
• Một quầy cho thuê xe khi nhận xe
• Một nhà tuyển dụng kiểm tra điều kiện sử dụng xe công ty
• Một công ty bảo hiểm xem xét yêu cầu bồi thường

Nếu IDP tương lai hiển thị cùng một dữ liệu cho cả bốn bên, hệ thống đã thất bại ngay từ đầu. Không phải vì thông tin xác thực không an toàn, mà vì mô hình công bố thông tin quá đơn giản.

Cộng đồng xây dựng tiêu chuẩn đã đang dần từ bỏ mô hình đơn giản đó. Công trình về verifiable credentials (thông tin xác thực có thể kiểm chứng) của W3C mô tả hệ sinh thái xung quanh các bên phát hành, người sở hữu và bên xác minh, sử dụng nhà tuyển dụng và trang web làm ví dụ về các bên xác minh. Công trình về giấy phép lái xe di động (mDL) của Liên minh Châu Âu (EU) đã coi việc kiểm tra tại hiện trường và cho thuê xe là các tình huống xác minh riêng biệt, bao gồm chia sẻ trước từ xa cho thuê xe và kiểm tra trực tiếp đối với cảnh sát. Kiến trúc đã được thiết kế cho nhiều loại bên xác minh. Sai lầm là thiết kế trải nghiệm người dùng như thể chỉ tồn tại một loại.

Tại Sao Thẻ Vật Lý Khiến Chúng Ta Suy Nghĩ Sai

Một giấy phép lái xe vật lý đã rèn luyện chúng ta theo cách tiếp cận hiển thị tất cả. Bạn đưa thẻ ra. Người kia nhìn thấy những gì có trên thẻ. Đó là toàn bộ tương tác.

Cách tiếp cận đó có thể chấp nhận được trong thế giới giấy tờ vì không có giải pháp thay thế. Nó trở nên không thể chấp nhận trong thế giới kỹ thuật số.

Mô hình Dữ Liệu VC 2.0 của W3C nêu rõ: một giấy phép lái xe có thể chứa số ID, chiều cao, cân nặng, ngày sinh và địa chỉ nhà — nhưng điều đó vẫn có thể vượt quá nhiều so với mức cần thiết cho một giao dịch cụ thể. Các điểm chính từ các tiêu chuẩn hiện hành:

• Thực tiễn tốt nhất của W3C: hỗ trợ công bố có chọn lọc và chỉ yêu cầu những gì thực sự cần thiết
• Hướng dẫn bảo vệ dữ liệu của EU: việc xử lý phải được giới hạn theo các mục đích đã xác định, và dữ liệu được xử lý phải cần thiết và tương xứng
• Nguyên tắc đầu tiên của IDP tương lai: cùng một thông tin xác thực không có nghĩa là cùng một quyền kiểm tra

Mô Hình Đúng Đắn Là Công Bố Dựa Trên Chính Sách

Nếu bạn muốn một kiến trúc nghiêm túc, mô hình đúng đắn gần với kiểm soát truy cập dựa trên thuộc tính hơn là trình bày thẻ kỹ thuật số.

NIST SP 800-205 định nghĩa các quyết định kiểm soát truy cập là việc đánh giá các thuộc tính liên quan đến chủ thể, đối tượng, thao tác được yêu cầu và điều kiện môi trường, dựa trên chính sách. Đó chính xác là cấu trúc phù hợp cho IDP tương lai:

• Chủ thể: tài xế
• Đối tượng: các trường dữ liệu được yêu cầu
• Hành động: không phải “xem giấy phép” một cách trừu tượng, mà là điều gì đó cụ thể như “xác minh quyền lái xe hạng B tại hiện trường” hay “xác minh điều kiện thuê xe cho một đặt chỗ”
• Môi trường: hiện trường, quầy cho thuê xe, kiểm tra trước từ xa, đăng ký đội xe và xem xét yêu cầu bồi thường sau sự cố là các môi trường khác nhau và nên dẫn đến các quyết định khác nhau

NIST cũng lưu ý rằng các hệ thống thuộc tính cần có độ chi tiết, quản trị và các cơ chế để giảm thiểu, nhóm và tối giản hóa thuộc tính.

Vì vậy, IDP tương lai không nên hỏi: Bên xác minh này có thể đọc giấy phép không? Mà nên hỏi: Bên xác minh này có thể nhận được những thông tin nào, cho mục đích sử dụng dự kiến nào, trong môi trường nào, với các quy tắc lưu trữ như thế nào?

Bên Xác Minh Phải Xác Định Danh Tính Của Mình Trước Khi Yêu Cầu Bất Cứ Điều Gì

IDP tương lai không nên bắt đầu bằng việc ví điện tử hiển thị dữ liệu. Nó nên bắt đầu bằng việc bên xác minh chứng minh họ là ai.

Kiến trúc EUDI rất rõ ràng về điều này. Các bên dựa trên thông tin xác thực (relying parties) phải:

• Đăng ký những thuộc tính họ dự định yêu cầu và vì mục đích gì
• Nhận chứng chỉ truy cập
• Xác thực với ví điện tử trước bất kỳ sự công bố nào
• Được kiểm tra đối chiếu với phạm vi đã đăng ký, khi thông tin đăng ký có sẵn

Người dùng sau đó có thể thấy ai đang hỏi, những gì đang được yêu cầu, và liệu yêu cầu có nằm trong phạm vi đã đăng ký hay không.

Công trình hiện tại của ETSI về chứng chỉ ví điện tử-bên dựa trên thông tin làm rõ điều này hơn. Một chứng chỉ đăng ký bên dựa trên ví điện tử có thể mô tả mục đích sử dụng dự kiến của bên đó và các thuộc tính mà họ đã đăng ký yêu cầu. Chứng chỉ truy cập liên quan tồn tại để đảm bảo yêu cầu đến từ một bên hợp lệ, được ủy quyền. ETSI cũng bao gồm siêu dữ liệu về bên dựa trên thông tin như:

• Tên thương mại
• URI hỗ trợ
• Mục đích sử dụng dự kiến
• Quyền hạn
• URI đăng ký
• Thông tin cơ quan giám sát

Nguyên tắc thứ hai của IDP tương lai: không có danh tính bên xác minh, không có công bố thông tin.

Tại Sao Màn Hình Đồng Ý Là Chưa Đủ

Có một sai lầm khác ở đây: coi sự chấp thuận của người dùng là giống với tính hợp pháp về mặt pháp lý.

Kiến trúc EUDI nêu rõ: sự chấp thuận của người dùng để trình bày các thuộc tính không được coi là căn cứ hợp pháp cho việc xử lý dữ liệu cá nhân của bên dựa trên thông tin. Bên dựa trên thông tin vẫn phải có cơ sở pháp lý riêng của mình. EUDI cũng yêu cầu sự chấp thuận của người dùng trong tất cả các trường hợp sử dụng, kể cả các trường hợp bên dựa trên thông tin có thể là một phần của cơ quan thực thi pháp luật hoặc cơ quan chính phủ khác.

Một giao diện ví điện tử tốt có thể giúp ích, nhưng nó không thể tự mình giải quyết vấn đề bên xác minh lạm dụng quyền hạn. Quy tắc phải tồn tại trước giao diện.

Do đó, một IDP tương lai cần cả hai:

• Xác thực bên xác minh bằng mật mã để xác nhận ai đang hỏi
• Ràng buộc chính sách về những gì danh mục bên xác minh đó có thể yêu cầu

Nếu thiếu một trong hai, “lựa chọn của người dùng” trở thành cách chuyển sự thất bại về chính sách sang cho cá nhân.

1. Cảnh Sát: Xác Minh Quyền Lái Xe, Không Phải Toàn Bộ Danh Tính

Tình huống kiểm tra của cảnh sát tại hiện trường là tình huống tập trung nhất.

Hướng dẫn mDL của EU mô tả trực tiếp: cảnh sát hoặc các quan chức khác kiểm tra giấy phép khi cần thiết, bao gồm hiệu lực của giấy phép và quyền sử dụng phương tiện. Trong hành trình người dùng, cảnh sát viên xác minh giấy phép thông qua quy trình kích hoạt bằng mã QR, Bluetooth, Wi-Fi Aware hoặc NFC. Đó là một nhiệm vụ xác minh tập trung:

• Người này có phải là chủ sở hữu giấy phép không?
• Thông tin xác thực có hợp lệ không?
• Quyền sử dụng và hạn chế đối với phương tiện nào được áp dụng?

Được phép theo mặc định:

• Họ tên
• Ảnh chân dung
• Tình trạng giấy phép
• Ngày cấp và ngày hết hạn
• Hạng xe
• Các hạn chế liên quan đến lái xe
• Cơ quan cấp và thẩm quyền tài phán
• Kết quả kiểm tra độ mới/tình trạng

Không được phép theo mặc định:

• Địa chỉ nhà
• Các mã định danh nội bộ không cần thiết cho mục đích kiểm tra tại hiện trường
• Các thuộc tính không liên quan từ các chứng thực khác
• Nhật ký trình bày lịch sử
• Siêu dữ liệu thương mại

Hướng dẫn triển khai của AAMVA củng cố điểm về ảnh chân dung: nếu ảnh chân dung được yêu cầu và bất kỳ yếu tố nào khác được công bố, ảnh chân dung phải được chia sẻ để bên xác minh có thể liên kết dữ liệu với người đang trình bày. Hướng dẫn tương tự cũng nêu rằng các bên liên quan không được theo dõi chủ sở hữu mDL hoặc việc sử dụng mDL ngoại trừ khi luật pháp yêu cầu.

Trường hợp cảnh sát không phải là về việc nhà nước nhận tất cả mọi thứ. Đó là về việc nhà nước nhận dữ liệu cụ thể liên quan đến lái xe cần thiết cho việc thực thi tại hiện trường. Đó là một sự khác biệt quan trọng.

2. Quầy Cho Thuê Xe: Điều Kiện Đủ, Xác Nhận Danh Tính và Không Gì Thừa

Trường hợp cho thuê xe chi tiết hơn vì thực sự có hai thời điểm: kiểm tra trước từ xa trước khi đến và khi nhận xe khi một người hoặc máy ki-ốt trao chìa khóa.

Hướng dẫn mDL của EU đã mô hình hóa cả hai. Một dịch vụ cho thuê xe có thể yêu cầu mDL cùng với bằng chứng danh tính trong quá trình đặt chỗ, xác nhận các chứng thực và sau đó xác minh khách hàng trực tiếp khi nhận xe trước khi giao phương tiện. Người dùng có thể chia sẻ mDL của họ với các công ty cho thuê xe trực tiếp hoặc từ xa trước.

Quầy cho thuê xe chủ yếu không cần điều tra một sự cố. Họ cần quyết định: Tôi có thể cho khách hàng này thuê phương tiện này theo đặt chỗ và chính sách này không?

Kiểm tra trước từ xa nên bao gồm:

• Liên kết danh tính
• Ảnh chân dung hoặc yếu tố ràng buộc danh tính tương đương
• Hạng phương tiện liên quan
• Ngày cấp và ngày hết hạn
• Hiệu lực hiện tại
• Có thể là ngưỡng tuổi hoặc nhóm tuổi

Khi nhận xe cần xác nhận:

• Người sở hữu là cùng một người đã hoàn tất kiểm tra trước
• Hiệu lực hiện tại
• Các quyền hạn liên quan

Không cần thiết theo mặc định:

• Địa chỉ nhà đầy đủ khi hồ sơ đặt chỗ đã chứa thông tin liên lạc
• Ngày sinh đầy đủ khi xác nhận tuổi-trên hoặc nhóm-tuổi là đủ
• Các thuộc tính danh tính không liên quan
• Trình bày lại nhiều lần thông tin xác thực đầy đủ nếu một chứng thực đặt chỗ đã tồn tại

Kiến trúc mDL hiện tại của NIST cho thấy bên dựa trên thông tin sử dụng DCQL để chỉ yêu cầu các thuộc tính cần thiết, và nêu rõ điều này hỗ trợ tối giản hóa dữ liệu và sự đồng ý của người sở hữu bằng cách cấu trúc yêu cầu thay vì coi thông tin xác thực như một đơn vị duy nhất. AAMVA bổ sung rằng ứng dụng nên hiển thị rõ ràng dữ liệu nào được yêu cầu và liệu bên xác minh có dự định lưu giữ thông tin hay không.

3. Nhà Tuyển Dụng: Một Danh Mục Bên Xác Minh, Không Phải Cửa Vào Toàn Bộ Danh Tính

Tổng quan của W3C sử dụng hệ thống kỹ thuật số của nhà tuyển dụng kiểm tra bằng đại học như một ví dụ về bên xác minh. Điều đó nhắc nhở chúng ta rằng xác minh của nhà tuyển dụng đã là một mô hình được công nhận trong hệ sinh thái thông tin xác thực.

Một nhà tuyển dụng hoặc người vận hành đội xe có thể hợp lệ cần biết:

• Liệu một nhân viên hiện có quyền lái một số hạng phương tiện nhất định không
• Liệu có tồn tại các hạn chế chính yếu nào không
• Liệu quyền hạn có còn hiệu lực không

Đó là nhu cầu kinh doanh thực sự. Nhưng nó không tự động biện minh cho quyền truy cập vĩnh viễn vào toàn bộ thông tin xác thực lái xe, dữ liệu danh tính đầy đủ hoặc một luồng liên tục các lần trình bày lặp đi lặp lại.

NIST cảnh báo rằng việc thường xuyên truyền tải một mã định danh có thể tái sử dụng và điều kiện hóa người dùng để liên tục trình bày thông tin xác thực mang danh tính là điều không mong muốn, và nêu rằng xác thực hàng ngày nên dựa trên các công nghệ được thiết kế cho xác thực, chẳng hạn như passkey. NIST ưu tiên xác thực thiết bị cục bộ hơn so với đối chiếu sinh trắc học phía máy chủ vì nó bảo vệ quyền riêng tư tốt hơn.

IDP tương lai không nên trở thành thẻ truy cập nơi làm việc.

Đối với mục đích sử dụng của nhà tuyển dụng và đội xe, mô hình đúng đắn thường là:

• Kiểm tra quyền hạn liên quan đến công việc
• Có thể là chứng thực tuân thủ định kỳ
• Có thể là thông tin xác nhận rằng người sở hữu vẫn hợp lệ đối với các hạng xe được chỉ định
• Nhưng không phải là việc chuyển giao mặc định tất cả dữ liệu giấy phép mỗi lần nhân viên đăng nhập vào hệ thống hoặc bắt đầu ca làm việc

Tuân thủ đội xe là một danh mục bên dựa trên thông tin riêng biệt, với mục đích sử dụng dự kiến riêng biệt và hồ sơ công bố riêng biệt.

4. Công Ty Bảo Hiểm: Yêu Cầu Bồi Thường Không Phải Là Sự Cho Phép Giám Sát Liên Tục

Trường hợp bảo hiểm thường rất thực tế. Trong tài liệu trường hợp sử dụng mDL của EU, các công ty bảo hiểm xuất hiện gián tiếp trong tình huống cho thuê xe: các công ty bảo hiểm yêu cầu các công ty cho thuê xe kiểm tra xem người thuê xe có quyền lái xe không. Bảo hiểm đã ảnh hưởng đến quy trình xác minh lái xe.

Nhưng điều đó không có nghĩa là một công ty bảo hiểm nên nhận cùng dữ liệu như cảnh sát, hoặc có quyền truy cập vĩnh viễn vào thông tin xác thực.

IDP tương lai nên coi các công ty bảo hiểm là một danh mục bên xác minh riêng biệt với các mục đích sử dụng dự kiến riêng biệt:

• Bảo lãnh bảo hiểm
• Xác minh rủi ro cho thuê xe
• Xử lý yêu cầu bồi thường sau sự cố
• Xem xét gian lận

Đó không phải là cùng một mục đích. Theo các nguyên tắc bảo vệ dữ liệu của EU, dữ liệu cá nhân phải được thu thập cho các mục đích đã xác định và giới hạn ở mức cần thiết và tương xứng cho mục đích đó. Hướng dẫn VC của W3C đạt đến kết luận tương tự về mặt kỹ thuật: các bên xác minh chỉ nên yêu cầu những gì thực sự cần thiết.

Ví dụ hợp lệ, dành riêng cho sự kiện:

• Bằng chứng rằng giấy phép có hiệu lực vào thời điểm liên quan
• Bằng chứng về quyền sử dụng phương tiện liên quan
• Bằng chứng liên kết danh tính khi cần thiết cho một yêu cầu bồi thường
• Công bố dành riêng cho yêu cầu bồi thường

Không được phép theo mặc định:

• Quyền truy cập liên tục vào thông tin xác thực cơ bản
• Xác minh chung lặp lại mỗi khi khách hàng tương tác với công ty bảo hiểm
• Sử dụng thông tin xác thực lái xe như một mã thông báo đăng nhập
• Thu thập các thuộc tính không liên quan

Thông tin xác thực lái xe không phải là gói đăng ký theo dõi. Và nó không nên lặng lẽ trở thành như vậy.

Tại Sao Các Bên Trung Gian Phải Được Hiển Thị Rõ Ràng

Thị trường thực tế liên quan đến các bên trung gian. Các nền tảng cho thuê xe, nhà cung cấp đội xe, hệ thống nhân sự của nhà tuyển dụng và bộ phận xử lý yêu cầu bồi thường bảo hiểm thường hoạt động thông qua các bên thứ ba.

Kiến trúc EUDI xử lý vấn đề này bằng cách:

• Coi các bên trung gian là các bên dựa trên thông tin
• Yêu cầu họ đăng ký
• Yêu cầu các thuộc tính được yêu cầu cho bên dựa trên thông tin qua trung gian phải được đăng ký
• Hiển thị cả bên trung gian và bên dựa trên thông tin cuối cùng cho người dùng
• Cấm các bên trung gian lưu trữ dữ liệu về nội dung giao dịch

IDP tương lai không bao giờ nên cho phép một mô hình mà người dùng nghĩ họ đang công bố thông tin cho công ty cho thuê xe, nhưng thực tế họ đang công bố cho một chuỗi môi giới xác minh vô hình, bộ xử lý phân tích và nhà cung cấp yêu cầu bồi thường.

ETSI hỗ trợ ở đây. Mô hình chứng chỉ bên dựa trên ví điện tử của họ bao gồm các URI hỗ trợ, mục đích sử dụng dự kiến, URI đăng ký và siêu dữ liệu cơ quan giám sát. Đó là loại cơ sở hạ tầng có thể đọc được bằng máy cần thiết để người dùng hiểu ai thực sự đứng ở đầu kia của yêu cầu và nơi để đến khi họ muốn xóa hoặc chỉnh sửa dữ liệu.

Lưu Giữ Dữ Liệu Là Một Phần Của Kiểm Soát Truy Cập

Hầu hết các cuộc thảo luận về công bố có chọn lọc kết thúc quá sớm. Họ tập trung vào những gì được công bố. Họ chưa tập trung đủ vào việc nó tồn tại bao lâu sau đó.

Hướng dẫn hiện tại đang dần hội tụ:

• AAMVA: ví điện tử phải thông báo rõ ràng cho người sở hữu dữ liệu nào được yêu cầu và liệu bên xác minh có dự định lưu giữ nó hay không; các bên liên quan không được theo dõi người sở hữu hoặc việc sử dụng mDL ngoại trừ khi luật pháp yêu cầu
• W3C: phần mềm người sở hữu nên cung cấp nhật ký thông tin được chia sẻ với các bên xác minh, để các yêu cầu quá mức có thể được xác định
• EUDI: người dùng nên có thể truy cập nhật ký giao dịch, báo cáo các yêu cầu đáng ngờ và yêu cầu xóa dữ liệu

Loại lưu giữ dữ liệu nên là một phần của chính sách công bố:

• Kiểm tra của cảnh sát tại hiện trường: không lưu giữ theo mặc định ngoài hồ sơ hoạt động hợp pháp
• Kiểm tra trước thuê xe từ xa: hồ sơ giao dịch gắn với đặt chỗ, không phải bản sao danh tính có thể tái sử dụng
• Tuân thủ đội xe của nhà tuyển dụng: hồ sơ tuân thủ hoặc kết quả chứng thực, không phải dữ liệu thông tin xác thực thô
• Yêu cầu bồi thường bảo hiểm: hồ sơ yêu cầu bồi thường giới hạn trong yêu cầu đó, không phải quyền truy cập vĩnh viễn

Một IDP tương lai bỏ qua vấn đề lưu giữ dữ liệu chỉ bảo vệ quyền riêng tư một phần.

Ví Điện Tử Thực Sự Nên Quyết Định Điều Gì

Nếu tôi phải rút gọn toàn bộ bài viết này thành một quy tắc triển khai duy nhất, đó sẽ là:

Ví điện tử không nên trả lời “Tôi có thể trình bày thông tin xác thực này không?” Nó nên trả lời “Tôi có thể trình bày tập hợp thông tin này cho bên xác minh đã được xác thực này, cho mục đích sử dụng dự kiến này, trong bối cảnh này, theo loại lưu giữ này không?”

Quyết định đó nên được dựa trên ít nhất các đầu vào sau:

• Danh tính bên xác minh
• Danh mục bên xác minh
• Mục đích sử dụng dự kiến
• Phạm vi thuộc tính đã đăng ký
• Chính sách công bố từ bên phát hành, nếu có
• Môi trường (hiện trường, nhận xe, từ xa, đội xe, yêu cầu bồi thường)
• Sự chấp thuận của người sở hữu
• Chính sách lưu giữ dữ liệu áp dụng

Các tiêu chuẩn đã chứa nhiều bộ máy cho điều này: công bố có chọn lọc, xác thực bên dựa trên thông tin, mục đích sử dụng dự kiến đã đăng ký, chứng chỉ truy cập, đánh giá chính sách công bố và các yêu cầu ràng buộc mục đích. Điều vẫn còn thiếu là kỷ luật để coi những phần đó như một kiến trúc công bố thông tin nhất quán.

Luận Điểm Cốt Lõi

IDP tương lai không nên hỏi liệu dữ liệu có thể được công bố hay không. Nó nên hỏi:

• Ai đang hỏi?
• Vì mục đích gì?
• Theo thẩm quyền nào?
• Trong bối cảnh nào?
• Với hậu quả lưu giữ như thế nào?

Cảnh sát, quầy cho thuê xe, nhà tuyển dụng và công ty bảo hiểm không phải là bốn logo ở đầu kia của một yêu cầu. Họ là bốn mô hình rủi ro khác nhau, bốn bối cảnh pháp lý khác nhau, bốn lý do hỏi khác nhau — và họ nên tạo ra bốn tập hợp công bố khác nhau.

Đó không phải là sự phức tạp không cần thiết. Đó là hình dạng của một thông tin xác thực lái xe hiện đại khi nó ngừng coi mọi bên xác minh là cùng một bên xác minh.