เรื่องยาวเกินไปเกี่ยวกับ DID

 (steveklabnik.com)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บัญชี Bluesky ไม่ได้ผูกกับแอปใดแอปหนึ่งโดยเฉพาะ สามารถใช้ได้กับหลายแอปที่อยู่บนพื้นฐาน atproto และ DID (ตัวระบุแบบกระจายศูนย์) ช่วยให้มีฐานสำหรับการยืนยันตัวตนที่แยกออกจากแอป
  • DID อยู่ในรูปแบบ did:<method>:<identifier> และใช้ กุญแจสาธารณะกับตำแหน่ง PDS ที่อยู่ใน DID Document เพื่อตรวจสอบความเชื่อมโยงระหว่างผู้เขียนโพสต์กับบัญชี
  • did:web เป็นวิธีเรียบง่ายที่ค้นหา /.well-known/did.json ของโดเมน แต่เปราะบางต่อ การพึ่งพา DNS และผู้รับจดทะเบียนโดเมน การหยุดทำงานของเว็บเซิร์ฟเวอร์ และความล่าช้าในการสะท้อนการเปลี่ยนแปลงของเอกสาร
  • did:plc ที่ Bluesky สร้างขึ้นแยก ID ออกจากโดเมนใดโดเมนหนึ่ง และให้ plc.directory รับภาระด้านการดำเนินงาน แต่แทนที่จะเชื่อถือ DNS ก็ต้อง เชื่อถือ plc.directory และใน Bluesky ไม่สามารถใช้วิธี DID ที่อิงบล็อกเชน เป็นต้น ได้
  • ผู้ใช้สามารถลงทะเบียนกุญแจเพิ่มเติม หมุนเวียนกุญแจ และรัน PDS ของตนเอง เพื่อเอากุญแจที่ Bluesky สร้างออก และ ควบคุมตัวตนของตนเองได้อย่างแท้จริง โดยไม่บังคับให้ทุกคนต้องจัดการกุญแจที่ซับซ้อน แต่ให้ทางเลือกแก่ผู้ที่ต้องการ

บัญชี Bluesky กับตัวตนบนฐาน DID

  • “บัญชี Bluesky” ไม่ใช่บัญชีที่ใช้เฉพาะใน Bluesky เท่านั้น แต่เป็นบัญชีที่ใช้ได้กับ หลายแอปพลิเคชันใน ATmosphere
  • atproto ซึ่งเป็นโปรโตคอลพื้นฐานของ Bluesky และแอปอื่น ๆ ใช้ DID เพื่อระบุว่าผู้ใช้เป็นใคร และเพื่อยืนยันการล็อกอินหรือผู้เขียนโพสต์
  • DID ที่ W3C ทำให้เป็นมาตรฐานในปี 2022 คือ Decentralized Identifier ที่แอปพลิเคชันใช้เป็นฐานของตัวตนได้
  • ความกระจายศูนย์ของ DID อยู่ที่ผู้ใช้สามารถเลือก DID method สำหรับตรวจสอบตัวตนของตนเองได้ แทนที่จะมีองค์กรเดียวเป็นผู้ตัดสินว่า DID ประเภทใดถูกต้อง
  • อย่างไรก็ตาม แอปพลิเคชันไม่สามารถจัดการ DID method ทั้งหมดได้โดยอัตโนมัติ
    • ต้องติดตั้งโค้ดรองรับแยกกันในแต่ละ method
    • หากแอปไม่รองรับ method foo ต่อให้ยื่น did:foo:1243 มาให้ ก็ไม่สามารถตีความได้

DID และ DID Document

  • DID ตัวอย่าง did:plc:3danwc67lo7obz2fmdg6jxcr ประกอบด้วยสามส่วนคั่นด้วยโคลอน
    • scheme: did
    • method: plc
    • ตัวระบุเฉพาะของ method: 3danwc67lo7obz2fmdg6jxcr
  • หากต้องการใช้ DID ต้อง resolve ให้เป็น DID Document
  • DID Document เก็บ ข้อมูลอย่างกุญแจสาธารณะทางคริปโตกราฟี เพื่อให้เจ้าของ DID หรือผู้ที่ได้รับมอบหมายสามารถยืนยันตัวเองและพิสูจน์ความเชื่อมโยงกับ DID นั้นได้
  • เอกสารตัวอย่างมีข้อมูลที่จำเป็นต่อการตรวจสอบตัวตน
    • id: DID นั้นเอง
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: ประเภท Multikey และ publicKeyMultibase
    • service: PDS endpoint ประเภท AtprotoPersonalDataServer
  • เมื่อโพสต์ใด ๆ อ้างว่าถูกเขียนโดยผู้ใช้รายหนึ่ง สามารถใช้ข้อมูลการตรวจสอบในเอกสารเพื่อตรวจสอบความจริงของคำอ้างนั้นได้
  • ขั้นตอนการ resolve DID ให้เป็นเอกสาร ถูกกำหนดโดยมาตรฐานของแต่ละ method
    • did:plc ทำตามมาตรฐาน PLC
    • อีกวิธีที่ Bluesky รองรับอย่าง did:web จะ resolve ด้วยวิธี Web

วิธี resolve ของ did:web

  • มีคนน้อยมากที่ใช้ did:web แต่โครงสร้างเรียบง่าย จึงเข้าใจกระบวนการ resolve DID ได้ง่าย
  • did:web:lizthegrey.com ของ Liz Fong-Jones จะนำ lizthegrey.com ซึ่งเป็นตัวระบุเฉพาะของ method ไปใส่ในเทมเพลต URL ต่อไปนี้เพื่อ resolve
https://<id>/.well-known/did.json
  • DID Document ที่ได้รับจาก URL ดังกล่าวมีข้อมูลต่อไปนี้
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: กุญแจสาธารณะ Multikey สำหรับ atproto
    • serviceEndpoint: https://pds.lizthegrey.com

ข้อจำกัดของ did:web

  • did:web พึ่งพา DNS และผู้รับจดทะเบียนโดเมน
    • หากผู้รับจดทะเบียนยึดโดเมนคืน ก็จะเสียสิทธิ์ควบคุม DID ไปด้วย
    • หากไม่ใช้โดเมนนั้นอีกต่อไป หรือโดเมนหมดอายุแล้วมีคนอื่นซื้อไป ก็อาจสูญเสียตัวตนได้
    • กรณีบัญชีผู้รับจดทะเบียนถูกแฮ็กจนโดเมนถูกยึดก็เช่นกัน
  • ต้องเปิดเว็บเซิร์ฟเวอร์ที่ให้บริการ DID Document ต่อเนื่อง และหากเซิร์ฟเวอร์หยุดทำงาน ก็จะดึงเอกสารไม่ได้
  • ไม่มีวิธีแจ้งไคลเอนต์ทันทีว่า DID Document เปลี่ยนแปลงแล้ว
    • แอปพลิเคชันอาจใช้เอกสารเก่าต่อไป
    • ความล่าช้าระหว่างการอัปเดตเอกสารกับการสะท้อนผลในแอปพลิเคชัน อาจทำให้เกิดปัญหาชั่วคราวจนกว่าจะดึงเอกสารล่าสุดมาใหม่

วิธีที่ did:plc เปลี่ยนการรักษาตัวตน

  • Bluesky พัฒนา did:plc เพื่อลดปัญหาของ did:web
  • did:plc นำ DID ทั้งหมดไปใส่ในเทมเพลต URL ต่อไปนี้เพื่อดึง DID Document
https://plc.directory/<did>;
  • แม้จะเหมือน did:web ตรงที่ค้นหา URL แต่แนวทางการดำเนินงานและการรักษาตัวตนต่างกัน
    • DID ไม่ผูกกับโดเมนใดโดเมนหนึ่ง จึงสามารถปล่อยให้ steveklabnik.com หมดอายุแล้วย้ายไป steve.klabnik.com ได้ โดยยังคง DID เดิม ไว้
    • การดูแลเว็บเซิร์ฟเวอร์ให้ plc.directory รับแทนผู้ใช้ จึงลดภาระการดำเนินงาน
  • ไม่ได้หมายความว่าวัตถุแห่งความเชื่อถือหายไปเอง
    • ใน did:web ต้องเชื่อถือ DNS และผู้รับจดทะเบียนโดเมน
    • ใน did:plc ต้องเชื่อว่า plc.directory จะไม่ยึด ID และจะไม่ถูกยึดไป
  • ผู้ใช้ที่มองว่าทั้ง DNS และ plc.directory ไม่น่าเชื่อถือ สามารถเลือก DID method อื่นที่ resolve ชื่อด้วยบล็อกเชน เป็นต้น ได้
  • แต่เนื่องจาก Bluesky ไม่รองรับ method เหล่านี้ จึง ไม่สามารถใช้ในแอปพลิเคชัน Bluesky ได้

ปัญหาด้านการเข้าถึงและวิธี DID แบบใหม่

  • หากตั้งค่า did:web ด้วยตนเอง จะต้องทำงานที่เป็นภาระสำหรับผู้ใช้ที่ไม่ใช่ผู้เชี่ยวชาญ
    • ต้องจดทะเบียนโดเมนและจ่ายค่าใช้จ่ายอย่างต่อเนื่อง
    • ต้องตั้งค่าเว็บเซิร์ฟเวอร์และเขียน JSON สำหรับ DID Document
    • ต้องให้เซิร์ฟเวอร์ทำงานต่อเนื่อง
    • ต้องจัดเก็บและจัดการ private key อย่างปลอดภัย
  • กระบวนการนี้ซับซ้อนกว่าการสมัครเว็บแอปทั่วไปมาก จึงไม่สอดคล้องกับเป้าหมายของ Bluesky ที่ต้องการให้ผู้ใช้ที่ไม่ใช่ผู้เชี่ยวชาญใช้งานแพลตฟอร์มได้ด้วย
  • หากให้ plc.directory จัดการงานที่เกี่ยวข้อง ผู้ใช้ก็ไม่ต้องทำขั้นตอนเหล่านี้ด้วยตนเอง
  • did:webvh เป็นวิธีที่ขยาย did:web เพื่อแก้ข้อเสียบางส่วน และ ไปถึงเวอร์ชัน 1.0 แล้ว แต่ไม่ได้รวมการเปรียบเทียบรายละเอียดของสเปกไว้ด้วย

วิธีเป็นเจ้าของตัวตนโดยตรงใน Bluesky

  • ในการตั้งค่าเริ่มต้น Bluesky จะสร้างคู่กุญแจของผู้ใช้และสามารถ เข้าถึง secret key ได้ ดังนั้นในแง่หนึ่งจึงอาจมองได้ว่า Bluesky เป็นเจ้าของตัวตน
  • did:plc สามารถลงทะเบียนคู่กุญแจเพิ่มเติมใน ID และหมุนเวียน signing key ได้
    • สามารถเอากุญแจที่ Bluesky สร้างออกได้
    • สามารถแทนที่ด้วยกุญแจที่ผู้ใช้สร้างเองได้
  • การเปลี่ยนกุญแจเพียงอย่างเดียวไม่ได้แยกออกจากโครงสร้างพื้นฐานของ Bluesky อย่างสมบูรณ์
    • หาก PDS จะเซ็นโพสต์ ต้องใช้กุญแจของผู้ใช้
    • หากใช้ PDS ที่ Bluesky จัดการ โดยทั่วไปกุญแจจะถูกเก็บไว้ในโครงสร้างพื้นฐานของ Bluesky
  • หากต้องการแยกตัวตนออกจาก Bluesky ต้อง รัน PDS ของตนเองแล้วหมุนเวียนกุญแจ
    • กุญแจจะถูกเก็บไว้ในโครงสร้างพื้นฐานที่ผู้ใช้เป็นเจ้าของ
    • หลังจากนั้น Bluesky จะไม่สามารถควบคุมกุญแจนั้นได้
  • แม้ผู้ใช้ส่วนใหญ่จะไม่เลือกการรัน PDS เองและจัดการกุญแจเอง แต่การที่ผู้ใช้ที่มีแรงจูงใจสามารถเป็นเจ้าของตัวตนได้อย่างแท้จริง ถือเป็นคุณสมบัติสำคัญด้านการออกแบบ
  • แนวทางที่ให้ผู้ใช้ที่ต้องการเลือกทำเองได้ แทนที่จะบังคับให้ผู้ใช้ทุกคนจัดการกุญแจด้วยตนเอง เหมาะสมกับผู้ใช้ส่วนใหญ่มากกว่า

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs
  • plc.directory ช่วงแรกอยู่ภายใต้การควบคุมของ Bluesky แต่ปัจจุบันกำลังอยู่ในกระบวนการแยกตัวเป็น องค์กรไม่แสวงหากำไรของสวิตเซอร์แลนด์
  • พูดตามตรง DID เป็นทางออกที่ดีกว่า SSO ของบริษัทเทคโนโลยีรายใหญ่ เพียงแต่ต้องให้คนทั่วไปใช้งานได้เหมือน did:plc: และแม้จะเป็นขององค์กรไม่แสวงหากำไร ก็ยังต้องพิจารณาว่าจะ เชื่อถือหน่วยงานกลางอย่างสมบูรณ์ ได้หรือไม่
    กำลังพัฒนาโปรเจกต์ที่นำ Keybase มาสร้างใหม่ พร้อมรองรับ W3C DID และ W3C Verifiable Credentials (VC) เป้าหมายคือพิสูจน์ความเป็นมนุษย์ได้แบบไม่ซ้ำกันและเป็นส่วนตัว พร้อมให้ผู้ใช้มี ตัวตนแบบกระจายศูนย์ ที่ตนควบคุมเอง
    • คุณกำลังพัฒนา FOKS อยู่หรือเป็นโปรเจกต์อื่น?
      https://foks.pub/
  • เห็นแค่ชื่อเรื่องแล้วนึกว่าจะลิงก์ไปยัง ข้อกำหนด DID แต่บทความจริงก็สั้นและมีประโยชน์
    • ลิงก์แรกของบทความก็คือ ลิงก์ข้อกำหนด นั่นเอง
  • สิ่งที่เพิ่งรู้วันนี้: DID ไม่ได้หมายถึง Docker in Docker
    • เพิ่งรู้เหมือนกันว่า Docker in Docker อาจอ่านเป็น DID ได้ ปกติได้ยินย่อว่า DinD หรือแบบที่ยิ่งสับสนกว่าอย่าง dind ไม่แน่ใจว่าเป็นธรรมเนียมในที่ทำงานหรือเป็นรูปแบบที่ใช้กันทั่วไป
    • และก็ไม่ได้หมายถึง Direct Inward Dialing ด้วย
  • สำหรับผู้อ่านที่ไม่ได้ใช้ Bluesky ช่วยนิยามได้ไหมว่า PDS คืออะไร?
    • PDS คือ Personal Data Server หมายถึงเซิร์ฟเวอร์ต้นทางของคอนเทนต์ เช่น โพสต์
    • Bluesky/AT ไม่ได้ใส่โพสต์ของผู้ใช้ทั้งหมดลงในฐานข้อมูลขนาดใหญ่เพียงชุดเดียว แต่เป็นโครงสร้างที่ผู้ใช้แต่ละคนมี ที่เก็บข้อมูลแยกต่างหาก เรียกว่า PDS สามารถใช้ PDS ที่ Bluesky ให้บริการ โฮสต์เอง หรือใช้บริการบุคคลที่สามก็ได้ และยังสามารถย้ายระหว่าง PDS ได้อย่างโปร่งใสโดยคงประวัติบัญชีทั้งหมดไว้
      ไม่เหมือนกับอินสแตนซ์ของ Mastodon และแนวคิดของ AT กับ ActivityPub ก็ไม่ได้สอดคล้องกันแบบหนึ่งต่อหนึ่งอย่างเรียบร้อย
  • ถ้า did:web ต้องโฮสต์เซิร์ฟเวอร์ .well-known และข้อมูลก็แทบจะเป็นแบบคงที่ ทำไมไม่ ใช้ DNS โดยตรง เหมือน TXT record ที่อ่านได้คล้าย URL มีโอกาสถูกแคชสูง และมีโอกาสหยุดทำงานโดยไม่ตั้งใจต่ำกว่า?
    ยังมีปัญหาเรื่องการพึ่งพา DNS และการตรวจจับการอัปเดต did.json ได้ไม่ง่าย แต่ถ้าวัตถุประสงค์คือการเชื่อมโยงโดเมนเฉพาะกับตัวตนของบุคคล ก็ดูเหมือนว่าการลดองค์ประกอบให้เหลือน้อยที่สุดและเชื่อมกับความสามารถของ DNS โดยตรงจะดีกว่า อยากรู้ว่ามีเหตุผลอะไรที่วิธีนี้ใช้ไม่ได้หรือทำได้ยากในทางปฏิบัติหรือไม่