Tôi luôn nghĩ rằng thiết kế "xác thực một lần dùng đi dùng lại" chỉ có lợi, cho đến khi tôi đổi góc nhìn và nhận ra ở đây có một điểm yếu mềm mà trước đó tôi chưa để ý.
Dusk của Citadel làm được như sau: tổ chức có thể yêu cầu bên thứ ba chứng minh một sự thật cụ thể nào đó về đối tác—chẳng hạn như "người này đủ điều kiện nhân sự" "người này không nằm trong danh sách trừng phạt" "khu vực pháp lý mà người này cư trú phù hợp"—và bản thân việc chứng minh này có thể được dùng lại, không cần mỗi lần lại xuất lại toàn bộ dữ liệu nền. Trước đây tôi hiểu nó như một "thẻ thông hành vạn năng đỡ phải nghĩ", và thấy rõ là chỉ có lợi. Nhưng sau đó tôi chợt hiểu ra một điều: việc "chứng chỉ" này rốt cuộc có đáng tin hay không, cuối cùng vẫn phụ thuộc vào mức độ đáng tin của bên cấp chứng chỉ.
Lấy ví dụ, nó giống như báo cáo tín dụng của bạn—ngân hàng, chủ nhà, và nhiều tổ chức khác đều chấp nhận báo cáo này. Bạn không cần mỗi lần lại phải tự chứng minh tình trạng tín dụng của mình, nên đúng là tiện. Nhưng điều kiện là tổ chức xuất báo cáo tín dụng đó phải đáng tin; nếu chính tổ chức này gặp vấn đề, hoặc dữ liệu bị nhiễm bẩn, thì mọi nơi dựa vào báo cáo đó cũng sẽ bị ảnh hưởng theo.
Thiết kế của Citadel không khiến việc "xác thực danh tính" biến mất, mà chỉ gom các công việc xác thực vốn bị phân tán ở nhiều nơi lại dồn vào đúng một khâu: khâu cấp chứng chỉ. Chi phí xác thực vì thế giảm đi, nhưng rủi ro cũng tập trung dồn về đúng một điểm. Theo tôi đây là một sự đánh đổi khá thực tế—tiện vì muốn đỡ tốn công, an toàn vì muốn giảm thiểu rủi ro; ở một mức độ nhất định, phải lấy cái này đổi cái kia, không phải là chuyện hời miễn phí.
Điều khiến tôi tò mò hơn hiện nay là: cơ chế chứng thực này, nếu thật sự xảy ra tranh chấp và phải đem ra tòa để tranh luận cho ra lẽ, rốt cuộc có chịu được phép thử không? Hiện tại tôi vẫn chưa tra được các ví dụ vụ việc thực tế.
Nếu là bạn, bạn sẽ lo ngại nhất khâu nào trong "xác thực một lần dùng đi dùng lại"?
@Dusk $DUSK #dusk