Quá nhiều điều để nói về DID

 (steveklabnik.com)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Tài khoản Bluesky không bị ràng buộc với một ứng dụng cụ thể mà có thể dùng trên nhiều ứng dụng dựa trên atproto, và DID (định danh phi tập trung) cung cấp nền tảng xác minh danh tính tách biệt khỏi ứng dụng
  • DID có dạng did:<method>:<identifier>, và dùng khóa công khai cùng vị trí PDS trong DID Document để xác minh mối liên hệ giữa người viết bài và tài khoản
  • did:web là cách đơn giản tra cứu /.well-known/did.json của một tên miền, nhưng dễ bị ảnh hưởng bởi sự phụ thuộc vào DNS·nhà đăng ký, gián đoạn máy chủ web và độ trễ trong việc phản ánh thay đổi tài liệu
  • did:plc do Bluesky tạo ra tách ID khỏi một tên miền cụ thể và để plc.directory gánh phần vận hành, nhưng thay vì DNS thì phải tin cậy plc.directory, và trong Bluesky không thể dùng các phương thức DID dựa trên blockchain
  • Người dùng có thể đăng ký thêm khóa, xoay vòng khóa và tự vận hành PDS để loại bỏ khóa do Bluesky tạo, qua đó thực chất tự kiểm soát danh tính, đồng thời không ép mọi người phải quản lý khóa phức tạp mà chỉ trao quyền lựa chọn cho ai muốn

Tài khoản Bluesky và danh tính dựa trên DID

  • “Tài khoản Bluesky” không phải là tài khoản chỉ dùng trong Bluesky mà là tài khoản có thể dùng trên nhiều ứng dụng trong ATmosphere
  • atproto, giao thức nền tảng của Bluesky và các ứng dụng khác, dùng DID để biểu thị người dùng là ai và để xác minh đăng nhập hay tác giả của bài viết
  • DID được W3C tiêu chuẩn hóa vào năm 2022 là một định danh phi tập trung có thể dùng làm nền tảng danh tính trong ứng dụng
  • Tính phi tập trung của DID nằm ở chỗ thay vì một cơ quan duy nhất quyết định kiểu DID nào là hợp lệ, người dùng có thể chọn phương thức DID để xác minh danh tính của mình
  • Tuy vậy, ứng dụng không thể tự động xử lý mọi phương thức DID
    • Mỗi phương thức cần được triển khai mã hỗ trợ riêng
    • Nếu ứng dụng không hỗ trợ phương thức foo thì dù đưa ra did:foo:1243 cũng không thể diễn giải được

DID và DID Document

  • DID ví dụ did:plc:3danwc67lo7obz2fmdg6jxcr gồm ba phần được phân tách bằng dấu hai chấm
    • Lược đồ: did
    • Phương thức: plc
    • Định danh theo phương thức: 3danwc67lo7obz2fmdg6jxcr
  • Để dùng DID, cần diễn giải nó thành DID Document
  • DID Document chứa dữ liệu như khóa công khai mật mã để chủ thể DID hoặc bên được ủy quyền có thể tự xác thực và chứng minh mối liên hệ với DID đó
  • Tài liệu ví dụ chứa thông tin cần thiết để xác minh danh tính
    • id: chính DID
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: kiểu Multikey và publicKeyMultibase
    • service: endpoint PDS kiểu AtprotoPersonalDataServer
  • Khi một bài viết bất kỳ tuyên bố là do một người dùng cụ thể tạo ra, có thể dùng thông tin xác minh trong tài liệu để kiểm tra tuyên bố đó có đúng không
  • Thủ tục diễn giải DID thành tài liệu được quy định theo tiêu chuẩn của từng phương thức
    • did:plc tuân theo tiêu chuẩn PLC
    • did:web, một cách khác mà Bluesky hỗ trợ, được diễn giải theo phương thức Web

Cách diễn giải did:web

  • Người dùng did:web rất ít, nhưng cấu trúc của nó đơn giản nên dễ hiểu quá trình diễn giải DID
  • did:web:lizthegrey.com của Liz Fong-Jones được diễn giải bằng cách đưa định danh theo phương thức lizthegrey.com vào mẫu URL sau
https://<id>/.well-known/did.json
  • DID Document nhận được từ URL đó chứa các thông tin sau
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: khóa công khai Multikey cho atproto
    • serviceEndpoint: https://pds.lizthegrey.com

Những ràng buộc của did:web

  • did:web phụ thuộc vào DNS và nhà đăng ký tên miền
    • Nếu nhà đăng ký thu hồi tên miền thì cũng mất quyền kiểm soát DID
    • Nếu không còn dùng tên miền đó nữa hoặc để hết hạn rồi người khác mua lại thì cũng có thể mất danh tính
    • Trường hợp tài khoản tại nhà đăng ký bị hack và tên miền bị chiếm đoạt cũng vậy
  • Cần tiếp tục vận hành máy chủ web phục vụ DID Document; nếu máy chủ ngừng hoạt động thì cũng không thể lấy tài liệu
  • Cũng không có cách nào báo ngay cho client biết DID Document đã thay đổi
    • Ứng dụng có thể tiếp tục dùng tài liệu cũ
    • Độ trễ giữa lúc cập nhật tài liệu và lúc ứng dụng phản ánh thay đổi có thể gây ra sự cố tạm thời cho đến khi tài liệu mới nhất được tải lại

did:plc thay đổi cách duy trì danh tính

  • Bluesky phát triển did:plc để giảm bớt các vấn đề của did:web
  • did:plc lấy DID Document bằng cách đưa toàn bộ DID vào mẫu URL sau
https://plc.directory/<did>;
  • Điểm giống với did:web là đều truy vấn một URL, nhưng cách vận hành và duy trì danh tính thì khác
    • DID không bị gắn với một tên miền cụ thể, nên dù để steveklabnik.com hết hạn và chuyển sang steve.klabnik.com thì vẫn giữ được cùng một DID
    • Việc vận hành máy chủ web do plc.directory đảm nhận thay cho người dùng nên giảm gánh nặng vận hành
  • Điều đó không có nghĩa là biến mất hoàn toàn đối tượng phải tin cậy
    • Với did:web, phải tin cậy DNS và nhà đăng ký tên miền
    • Với did:plc, phải tin rằng plc.directory sẽ không cướp ID và cũng không bị xâm nhập
  • Người dùng cho rằng cả DNS lẫn plc.directory đều không đáng tin có thể chọn các phương thức DID khác, chẳng hạn diễn giải tên bằng blockchain
  • Tuy nhiên Bluesky không hỗ trợ các phương thức đó, nên không thể dùng trong ứng dụng Bluesky

Vấn đề tiếp cận và các phương thức DID mới

  • Để tự thiết lập did:web, người dùng không chuyên phải làm nhiều việc khá nặng nề
    • Đăng ký tên miền và liên tục trả phí duy trì
    • Cấu hình máy chủ web và viết JSON cho DID Document
    • Giữ máy chủ luôn hoạt động
    • Lưu trữ và quản lý an toàn khóa riêng
  • Quy trình này phức tạp hơn rất nhiều so với đăng ký một ứng dụng web thông thường, nên không phù hợp với mục tiêu của Bluesky là để cả người dùng không chuyên cũng có thể sử dụng nền tảng
  • Nếu plc.directory quản lý phần việc liên quan thì người dùng không cần tự làm các bước này
  • did:webvh là một cách mở rộng did:web để khắc phục một số nhược điểm và đã đạt 1.0, nhưng bài viết không đi sâu so sánh đến mức đặc tả chi tiết

Cách thực sự sở hữu danh tính trong Bluesky

  • Ở thiết lập mặc định, Bluesky tạo cặp khóa cho người dùng và có quyền truy cập khóa bí mật, nên theo một nghĩa nào đó có thể xem Bluesky là bên sở hữu danh tính
  • did:plc cho phép đăng ký thêm cặp khóa cho ID và xoay vòng khóa ký
    • Có thể loại bỏ khóa do Bluesky tạo
    • Có thể thay bằng khóa do chính người dùng tạo
  • Chỉ thay khóa thôi vẫn chưa hoàn toàn tách khỏi hạ tầng Bluesky
    • PDS phải dùng khóa của người dùng để ký bài viết
    • Nếu dùng PDS do Bluesky quản lý thì khóa thường được lưu trong hạ tầng Bluesky
  • Để tách Bluesky khỏi danh tính, cần tự vận hành PDS rồi xoay vòng khóa
    • Khi đó khóa được lưu trong hạ tầng do người dùng sở hữu
    • Sau đó Bluesky không còn kiểm soát được khóa đó
  • Dù phần lớn người dùng có thể không chọn tự vận hành PDS và tự quản lý khóa, việc những người có động lực có thể thực sự sở hữu danh tính vẫn là một thuộc tính thiết kế quan trọng
  • Thay vì buộc mọi người dùng phải trực tiếp quản lý khóa, cách tiếp cận cho phép ai muốn thì có thể chọn sẽ phù hợp hơn với đa số người dùng

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Các ý kiến trên Lobste.rs
  • Ban đầu plc.directory do Bluesky kiểm soát, nhưng hiện đang trong quá trình tách ra thành một tổ chức phi lợi nhuận của Thụy Sĩ độc lập
  • Thành thật mà nói, DID là một giải pháp tốt hơn so với đăng nhập một lần (SSO) hợp nhất của các công ty công nghệ lớn. Tuy nhiên, nó cần phải usable cho cả người dùng phổ thông như did:plc:, và dù thuộc sở hữu của một tổ chức phi lợi nhuận thì vẫn cần cân nhắc liệu có nên hoàn toàn tin tưởng một cơ quan trung ương hay không
    Tôi đang phát triển một dự án tái triển khai Keybase, đồng thời hỗ trợ W3C DID và W3C Verifiable Credentials (VC). Mục tiêu là chứng minh một cách duy nhất nhưng riêng tư rằng một người là con người, và giúp họ có danh tính phi tập trung do chính họ kiểm soát
    • Có phải bạn đang phát triển FOKS không, hay là một dự án khác?
      https://foks.pub/
  • Nhìn tiêu đề tôi tưởng sẽ dẫn đến đặc tả DID, nhưng bài viết thực tế cũng ngắn gọn và hữu ích
    • Liên kết đầu tiên trong bài chính là liên kết tới đặc tả
  • Điều biết được hôm nay: DID không phải là Docker in Docker
    • Lần đầu tôi biết Docker in Docker cũng có thể được đọc là DID. Tôi luôn nghe nó được viết tắt là DinD hoặc dạng còn dễ gây nhầm lẫn hơn là dind, nhưng không rõ đó là thông lệ ở chỗ làm hay cách viết phổ biến
    • Cũng không phải là viết tắt của Direct Inward Dialing
  • Bạn có thể định nghĩa PDS là gì cho những độc giả không dùng Bluesky không?
    • PDS là Personal Data Server, tức máy chủ gốc cho nội dung như bài đăng
    • Bluesky/AT không đưa bài đăng của mọi người dùng vào một cơ sở dữ liệu lớn duy nhất, mà có cấu trúc trong đó mỗi người dùng có một kho dữ liệu riêng gọi là PDS. Bạn có thể dùng PDS do Bluesky cung cấp, tự host, hoặc dùng dịch vụ bên thứ ba, và cũng có thể di chuyển minh bạch giữa các PDS trong khi vẫn giữ toàn bộ lịch sử tài khoản
      Nó không giống instance của Mastodon; các khái niệm của AT và ActivityPub không tương ứng một-một một cách gọn gàng
  • Nếu did:web phải host máy chủ .well-known và dữ liệu cũng gần như tĩnh, tại sao không dùng trực tiếp DNS, vốn có thể đọc gần giống URL như bản ghi TXT, có khả năng được cache cao và ít có khả năng bị gián đoạn ngoài ý muốn hơn?
    Vẫn còn vấn đề phụ thuộc vào DNS và khó phát hiện việc cập nhật did.json, nhưng nếu mục đích là liên kết một tên miền cụ thể với danh tính của một cá nhân, thì có vẻ tốt hơn là tối giản các thành phần và nối trực tiếp vào chức năng của DNS. Tôi tò mò liệu có lý do nào khiến cách này không hoạt động hoặc khó khả thi trong thực tế không