---
title: "อัตลักษณ์แบบกระจายศูนย์ (DID)"
description: "คู่มือเชิงปฏิบัติสำหรับตัวระบุแบบกระจายศูนย์และข้อมูลประจำตัวที่ตรวจสอบได้: สิ่งที่พิสูจน์ได้ ขั้นตอนการออกและนำเสนอ ตลอดจนความเสี่ยงด้านความไว้วางใจ ความเป็นส่วนตัว และการกู้คืนที่ยังคงอยู่"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# อัตลักษณ์แบบกระจายศูนย์ (DID)

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

อัตลักษณ์แบบกระจายศูนย์คือสถาปัตยกรรมที่ประธานของอัตลักษณ์ใช้ตัวระบุและข้อมูลประจำตัวที่ป้องกันด้วยการเข้ารหัสในหลายบริการ โดยไม่ทำให้บัญชีแพลตฟอร์มหนึ่งเป็นแหล่งอัตลักษณ์สากล องค์ประกอบทั่วไปได้แก่ตัวระบุแบบกระจายศูนย์ (DID) ข้อมูลประจำตัวที่ตรวจสอบได้ (VC) ซอฟต์แวร์ของผู้ถือ เช่น กระเป๋า และกฎที่บอกผู้ตรวจสอบว่าจะยอมรับผู้ออก หลักฐาน และระดับความเชื่อมั่นใด

DID เป็น URI เช่น `did:example:123` วิธี DID กำหนดการสร้าง การแก้ระเบียน การอัปเดต และการปิดใช้งาน การแก้ระเบียนอาจคืนเอกสาร DID ที่มีวิธีตรวจสอบ ความสัมพันธ์อย่าง `authentication` หรือ `assertionMethod` และปลายทางบริการเสริม การควบคุมกุญแจที่ตรงกันพิสูจน์การควบคุม DID ภายใต้วิธีนั้น แต่เพียงอย่างเดียวไม่พิสูจน์ชื่อตามกฎหมาย อายุ ความเป็นบุคคลเดียว การจ้างงาน หรือเจ้าของบัญชีภายนอก

ข้อมูลประจำตัวที่ตรวจสอบได้บรรจุคำกล่าวของผู้ออกเกี่ยวกับประธานหนึ่งรายหรือมากกว่า ผู้ถือเก็บข้อมูลดังกล่าวและสร้างการนำเสนอที่ตรวจสอบได้แก่ผู้ตรวจสอบ การตรวจสอบทางการเข้ารหัสที่สำเร็จยืนยันความสมบูรณ์และผู้สร้างข้อมูลที่ป้องกันภายใต้กลไกที่เลือก ผู้ตรวจสอบยังต้องตัดสินแยกต่างหากว่าจะเชื่อผู้ออกหรือไม่ คำกล่าวตรงตามนโยบายหรือไม่ ข้อมูลประจำตัวยังใช้ได้หรือไม่ และผู้นำเสนอมีสิทธิ์ใช้หรือไม่

ดังนั้น “กระจายศูนย์” ไม่ได้แปลว่าไม่ต้องไว้วางใจ ไม่ระบุตัวตน ต้องใช้บล็อกเชน หรือไม่มีตัวกลาง แต่หมายถึงสามารถแยกตัวระบุ ข้อมูลประจำตัว รีจิสทรี กระเป๋า และนโยบายตรวจสอบ เพื่อไม่ให้ผู้ให้บริการเข้าสู่ระบบรายเดียวมองเห็นและควบคุมทุกความสัมพันธ์ ระดับการกระจายศูนย์จริงขึ้นกับผู้ออก ผู้ดำเนินวิธี DID บริการสถานะ ผู้ให้บริการกระเป๋า ผู้ดูแลการกู้คืน กุญแจธรรมาภิบาล และนโยบายผู้ตรวจสอบ

<a id="mechanism"></a>

## วิธีทำงาน

1. **กำหนดคำกล่าวและกรอบความไว้วางใจ** ระบุประธาน แอตทริบิวต์ที่ขอ ผู้ออกที่ยอมรับ กระบวนการพิสูจน์ ระดับความเชื่อมั่น การเก็บรักษา เขตอำนาจ และทางอุทธรณ์ รูปแบบการเข้ารหัสไม่อาจตัดสินว่ามหาวิทยาลัย รัฐบาล นายจ้าง หรือชุมชนเป็นผู้มีอำนาจที่เหมาะสมหรือไม่
2. **สร้างหรือรับตัวระบุและกุญแจ** ผู้ออกและผู้ถือใช้ DID, HTTPS URL หรือตัวระบุอื่นที่รองรับได้ หากใช้ DID วิธีจะกำหนดรีจิสทรีและวงจรชีวิต ผู้ควบคุมป้องกันกุญแจส่วนตัว ส่วนเอกสารที่แก้ระเบียนแล้วเปิดเผยเฉพาะวัสดุตรวจสอบและปลายทางที่จำเป็น
3. **พิสูจน์และผูกประธาน** ผู้ออกตรวจหลักฐานตามนโยบายแล้วผูกคำกล่าวกับประธานของข้อมูลประจำตัว การผูกอาจอ้างถึงกุญแจที่ผู้ถือควบคุม บัญชี หรือตัวระบุอื่น ต้องแยกหลักฐานเกี่ยวกับบุคคลออกจากหลักฐานว่าผู้นำเสนอปัจจุบันควบคุมกุญแจ
4. **ออกข้อมูลประจำตัว** ผู้ออกสร้างคำกล่าว วันที่มีผล สคีมาหรือชนิด และการอ้างสถานะ แล้วป้องกันด้วยหลักฐานที่รองรับ ใน Data Integrity ช่อง `cryptosuite`, `verificationMethod`, `proofPurpose` และ `proofValue` ระบุวิธีตรวจสอบหลักฐาน
5. **จัดเก็บและเลือก** ผู้ถือเก็บข้อมูลประจำตัวในกระเป๋าแบบท้องถิ่นหรือโฮสต์ กระเป๋าควรอธิบายคำขอ เปิดเผยเฉพาะข้อมูลจำเป็นเมื่อรูปแบบรองรับ และไม่ใช้ตัวระบุคงที่ซ้ำอย่างเงียบ ๆ ในบริบทที่ไม่เกี่ยวข้อง
6. **นำเสนอพร้อมความสดใหม่และการผูกผู้รับ** ผู้ตรวจสอบส่งอัตลักษณ์ วัตถุประสงค์ nonce หรือ challenge และเวลาหมดอายุ ผู้ถือส่งข้อมูลประจำตัวหรือการนำเสนออนุพันธ์ที่ผูกกับคำขอ การตรวจโดเมนและ challenge ช่วยป้องกันการนำไปใช้ซ้ำกับผู้ตรวจสอบหรือเซสชันอื่น
7. **ตรวจการเข้ารหัสและนโยบาย** แก้วัสดุตรวจสอบของผู้ออกจากแหล่งที่พิสูจน์ตัวตน ตรวจชุด วัตถุประสงค์ challenge โดเมน วันที่ สคีมา และสถานะ แล้วใช้กฎธุรกิจ ผล `verified: true` เป็นข้อมูลเข้าเพื่ออนุญาต ไม่ใช่คำสั่งให้เข้าถึง
8. **ดำเนินวงจรชีวิต** หมุนกุญแจที่รั่ว ระงับหรือเพิกถอนข้อมูลประจำตัว อัปเดตสถานะ จัดให้มีการกู้คืนและอุทธรณ์ เก็บหลักฐานตรวจสอบ และเผยแพร่แผนย้ายหรือปิด การตรวจสอบย้อนหลังต้องมีกฎชัดเจนสำหรับกุญแจ เอกสาร และเวลานำเสนอเดิม

บทบาทหลักสามฝ่ายคือ **ผู้ออก** **ผู้ถือ** และ **ผู้ตรวจสอบ** โดยประธานของข้อมูลประจำตัวอาจไม่ใช่ผู้ถือ เช่น ผู้ปกครองอาจถือข้อมูลเกี่ยวกับเด็ก หรือตัวแทนบริษัทนำเสนอข้อมูลเกี่ยวกับองค์กร ระบบต้องไม่สันนิษฐานว่าผู้นำเสนอคือประธาน เว้นแต่ข้อมูลประจำตัวและโพรโทคอลสร้างการผูกนั้น

DID และ VC เป็นอิสระต่อกัน VC ใช้ตัวระบุผู้ออกที่ไม่ใช่ DID ได้ และ DID ใช้โดยไม่มี VC ได้ วิธี DID อาจใช้บล็อกเชน ฐานข้อมูลกระจาย โดเมนเว็บ หรือการแลกเปลี่ยนแบบเพียร์ทูเพียร์ ต้องประเมินความปลอดภัยและธรรมาภิบาลโดยตรง ไม่อนุมานจากคำนำหน้า `did:`

<a id="example"></a>

## ตัวอย่างเชิงปฏิบัติ

สมมติว่าบริการต้องยืนยันว่าลูกค้ามีอายุอย่างน้อย 18 ปีโดยไม่เก็บวันเกิด หน่วยงานที่ยอมรับตรวจลูกค้าแล้วออกข้อมูลประจำตัวอายุเข้ากระเป๋า ข้อมูลอาจมีวันเกิดหรือมีเพียงคำกล่าว `ageOver18` ซึ่งให้คุณสมบัติการเปิดเผยและใช้ซ้ำต่างกัน

เมื่อลงทะเบียน บริการขอการนำเสนออายุเกิน 18 สำหรับ `merchant.example` พร้อม challenge `n-7f3a` และช่วงใช้ได้ 5 นาที กระเป๋าแสดงคำขอ และหากข้อมูลกับชุดหลักฐานรองรับ ก็สร้างการนำเสนอที่เผยเฉพาะเงื่อนไขจำเป็น บริการตรวจวิธี หลักฐาน challenge โดเมน ช่วงเวลา และสถานะ ก่อนบันทึกผลขั้นต่ำที่นโยบายตรวจสอบต้องการ

ขั้นตอนนี้ลดความจำเป็นเก็บภาพเอกสารหรือวันเกิดเต็ม แต่ไม่ขจัดความไว้วางใจหรือความเสี่ยง หน่วยงานอาจลงทะเบียนผิดคน กระเป๋าหรืออุปกรณ์อาจถูกเจาะ ตัวระบุคงที่หรือคำขอสถานะอาจเชื่อมการใช้งาน บริการอาจขอข้อมูลมากเกิน หรือการระงับผิดอาจปฏิเสธการเข้าถึง การเปิดเผยแบบเลือกจำกัดข้อมูลในการนำเสนอ ไม่ใช่เมทาดาทาทั้งหมดที่ผู้ออก กระเป๋า เครือข่าย และผู้ตรวจสอบมองเห็น

การหมุนกุญแจแสดงขอบเขตอีกประการ หากผู้ออกเปลี่ยนกุญแจที่รั่ว ข้อมูลประจำตัวใหม่ควรใช้วิธีตรวจสอบใหม่ ข้อมูลเก่ายังตรวจได้หรือไม่ขึ้นกับประวัติวิธี DID เวลาสร้างหลักฐาน นโยบายผู้ตรวจสอบ และสถานะ การลบกุญแจเก่าออกจากเอกสาร DID ปัจจุบันเพียงอย่างเดียวอาจทำให้การตรวจย้อนหลังที่ชอบธรรมล้มเหลวหรือซ่อนว่ากุญแจใดได้รับอนุญาตตอนสร้างหลักฐาน

<a id="risks"></a>

## ความเสี่ยงและการควบคุม

- **คำกล่าวเท็จหรือกว้างเกินไป:** ลายเซ็นที่ถูกต้องรักษาสิ่งที่ผู้ออกกล่าว แต่ไม่ทำให้ถูกต้อง ต้องกำหนดหลักฐาน ความรับผิด ระดับความเชื่อมั่น การตรวจสอบ วันหมดอายุ และการแก้ไข
- **การผูกผู้ถืออ่อนแอ:** สำเนาอาจถูกผู้อื่นใช้ หากการนำเสนอไม่พิสูจน์การควบคุมกุญแจหรือตัวพิสูจน์ที่ตั้งใจไว้ ควรผูกหลักฐานการครอบครองกับผู้ตรวจสอบ challenge วัตถุประสงค์ และเซสชันเมื่อเหมาะสม
- **กุญแจและกระเป๋าถูกเจาะ:** มัลแวร์ ฟิชชิง การยึดกระเป๋าคลาวด์ หรือข้อมูลสำรองไม่ปลอดภัยอาจเปิดเผยข้อมูลและกุญแจ ใช้การยืนยันตัวตนต้านฟิชชิง การป้องกันฮาร์ดแวร์เมื่อสมควร การแจ้งเหตุ และการกู้คืนขอบเขตแคบ
- **การกู้คืนรวมศูนย์:** ผู้ดูแลรายเดียวอาจเป็นผู้ควบคุมอัตลักษณ์ตัวจริง ต้องระบุว่าใครเปลี่ยนกุญแจ หลักฐานใดจำเป็น วิธีพบการใช้ผิด และผู้ใช้จะอุทธรณ์หรือย้ายอย่างไร
- **การเชื่อมโยง:** การใช้ DID วิธี รูปแบบลายเซ็น ปลายทาง หรือเส้นทางสถานะซ้ำอาจเชื่อมกิจกรรมระหว่างบริการ ใช้ตัวระบุแบบคู่ กุญแจหรือหลักฐานแยกโดเมน สถานะรักษาความเป็นส่วนตัว และทดสอบเมทาดาทา
- **ข้อมูลส่วนบุคคลสาธารณะ:** เอกสาร DID และประวัติรีจิสทรีอาจถูกทำดัชนีและลบยาก อย่าใส่ชื่อ หมายเลขเอกสาร ไบโอเมตริก หรือคำกล่าวส่วนบุคคลในเอกสารสาธารณะและรีจิสทรีแก้ไม่ได้
- **ความเป็นส่วนตัวและความพร้อมของสถานะ:** การติดต่อผู้ออกทุกครั้งเผยว่าข้อมูลถูกใช้ที่ไหน ส่วนการล่มขวางผู้ใช้ที่ถูกต้อง เลือกสถานะรักษาความเป็นส่วนตัวที่แคชได้ มีขีดจำกัดความสด การอัปเดตพิสูจน์ตัวตน และพฤติกรรมล้มเหลวชัดเจน
- **การใช้การเพิกถอนผิด:** ผู้ออกหรือผู้ดูแลอาจเซ็นเซอร์ผู้ถือด้วยการระงับหรือเปลี่ยนสถานะ จำกัดอำนาจ บันทึกการเปลี่ยน แสดงเหตุผลและการอุทธรณ์ และรองรับการแทนที่หรือผู้ออกทางเลือก
- **ความเสี่ยงการแก้ระเบียนและวิธี:** ตัวแก้อาจคืนเอกสารเก่าหรืออันตราย และวิธีอาจพึ่งโครงสร้างรวมศูนย์ พิสูจน์ผลและประเมินความสิ้นสุด อำนาจอัปเดต ความพร้อม ธรรมาภิบาล และรุ่น
- **ความหมายไม่ตรงกัน:** สองระบบอาจอ่านช่องเดียวกันแต่ตีความคำกล่าว หน่วย เขตอำนาจ หรือระดับความเชื่อมั่นต่างกัน ใช้สคีมาและคำศัพท์คงที่ ตรวจบริบทและชนิด และกำหนดรุ่นความหมายของนโยบาย
- **การเล่นซ้ำและสับสนผู้ตรวจสอบ:** การนำเสนอที่ไม่ผูกกับ nonce ผู้รับ โดเมน การกระทำ และการหมดอายุอาจใช้ซ้ำหรือเปลี่ยนปลายทาง ตรวจทุกการผูกที่โพรโทคอลกำหนด
- **การเปิดเผยมากเกิน:** แม้กระเป๋ารองรับการเปิดเผยแบบเลือก ผู้ตรวจสอบอาจขอข้อมูลทั้งหมด บังคับการลดข้อมูลในนโยบายและหน้าจอ บันทึกวัตถุประสงค์ และอย่าเปลี่ยนช่องเสริมเป็นช่องบังคับเพราะความเคยชิน
- **การผูกขาดระบบนิเวศ:** กระเป๋า หลักฐาน รีจิสทรี หรือการกู้คืนแบบกรรมสิทธิ์ลดการพกพา ทดสอบมาตรฐาน การส่งออก หลายกระเป๋า ความคล่องตัวด้านการเข้ารหัส และการย้ายก่อนใช้จริง
- **การครอบงำธรรมาภิบาล:** มัลติซิกหรือรีจิสทรีไม่รับประกันการควบคุมกว้าง หากผู้ขายรายเดียวเลือกผู้ออก การอัปเดต สคีมา และสถานะ ต้องทำแผนอำนาจรายองค์ประกอบและเผยแพร่การควบคุมการเปลี่ยน

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- **“DID พิสูจน์ว่าบุคคลคือใคร”** DID ระบุประธานและแสดงวิธีตรวจสอบได้ แต่แอตทริบิวต์ต้องมีคำกล่าว หลักฐาน และการตัดสินใจไว้วางใจเพิ่มเติม
- **“ข้อมูลประจำตัวที่ถูกต้องทำให้คำกล่าวเป็นจริง”** การตรวจแสดงหลักฐานที่คาดและว่าข้อมูลไม่ถูกแก้ ไม่ได้ยืนยันการสืบสวนหรือการตัดสินเดิมของผู้ออก
- **“ผู้ถือคือประธานของข้อมูลประจำตัวเสมอ”** บทบาทอาจต่างกัน จึงต้องมีการผูกประธานกับผู้นำเสนออย่างชัดเจนเมื่อกรณีใช้งานต้องการ
- **“ทุกอย่างควรอยู่บนเชน”** ที่เก็บสาธารณะแก้ไม่ได้เพิ่มความเสี่ยงด้านความเป็นส่วนตัว การเชื่อมโยง การลบ และธรรมาภิบาล หลายระบบเก็บข้อมูลประจำตัวนอกเชน
- **“การเปิดเผยแบบเลือกรับประกันการไม่ระบุตัวตน”** แอตทริบิวต์ ตัวระบุคงที่ ลายนิ้วมือหลักฐาน คำขอสถานะ เวลา IP และบันทึกผู้ออกยังเชื่อมการนำเสนอได้
- **“กระจายศูนย์แปลว่าไม่มีผู้ออกหรือผู้ดูแลที่ต้องเชื่อถือ”** ความไว้วางใจถูกกระจายและทำให้ชัด ไม่ได้ถูกลบ การออก การพิสูจน์ กระเป๋า การกู้คืน สถานะ และการยอมรับยังถูกกำกับ
- **“DID หนึ่งตัวเท่ากับมนุษย์หนึ่งคน”** คนหนึ่งควบคุมหลาย DID ได้ และ DID อาจระบุองค์กร อุปกรณ์ ข้อมูล บทบาท หรือประธานอื่น ความเป็นหนึ่งเดียวและความเป็นมนุษย์ต้องมีกลไกแยก
- **“ลายเซ็นกระเป๋าเพียงพอสำหรับยืนยันตัวตน”** มันพิสูจน์การควบคุมกุญแจภายใต้เงื่อนไขที่กำหนด แอปยังต้องต้านฟิชชิง ตรวจความสด ผูกผู้รับ ให้อำนาจ และมีกฎกู้บัญชี

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [ตัวสะสมเชิงเข้ารหัส](/crypto/cryptographic-accumulator/)
- [การพิสูจน์ความเป็นมนุษย์](/crypto/proof-of-personhood/)
- [การโจมตีซีบิล](/crypto/sybil-attack/)
- [ลายเซ็นกระเป๋า](/crypto/wallet-signature/)
- [การพิสูจน์แบบไม่เปิดเผยความรู้](/crypto/zero-knowledge-proof/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-1.0/) - W3C (เข้าถึง: 2026-08-20)
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - W3C (เข้าถึง: 2026-08-20)
- [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) - W3C (เข้าถึง: 2026-08-20)
- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) - W3C (เข้าถึง: 2026-08-20)
- [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) - NIST (เข้าถึง: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/decentralized-identity/index.mdx