Verifiable Credentials Data Model 2.0: ก้าวสำคัญของมาตรฐานดิจิทัลไอดีสู่ยุคใหม่แห่งความปลอดภัยและความเป็นส่วนตัว

บทนำและที่มาของมาตรฐาน
Verifiable Credentials (VC) เป็นมาตรฐานสำคัญที่ได้รับการพัฒนาโดย World Wide Web Consortium หรือ W3C ซึ่งเป็นองค์กรที่กำหนดมาตรฐานเว็บระดับโลก มาตรฐานนี้ถูกออกแบบมาเพื่อแก้ไขปัญหาพื้นฐานของการจัดการข้อมูลประจำตัวดิจิทัลในโลกออนไลน์ที่มีความซับซ้อนมากขึ้นทุกวัน ในยุคที่ทุกอย่างเปลี่ยนเป็นดิจิทัล การพิสูจน์ตัวตนและการยืนยันข้อมูลประจำตัวกลายเป็นความท้าทายใหญ่ที่ต้องการแนวทางใหม่ที่มีความปลอดภัย สามารถตรวจสอบได้ และเคารพสิทธิความเป็นส่วนตัวของผู้ใช้

เวอร์ชัน 1.0 และ 1.1 ของ Verifiable Credentials Data Model ถูกเผยแพร่ครั้งแรกในปี 2019 และได้รับการปรับปรุงในปี 2022 ตามลำดับ มาตรฐานเหล่านี้ได้วางรากฐานสำคัญสำหรับระบบ digital identity ที่ทันสมัย โดยเวอร์ชัน 1.1 กลายเป็นมาตรฐานที่ได้รับการยอมรับและนำไปใช้งานจริงในหลายองค์กรทั่วโลก อย่างไรก็ตาม จากประสบการณ์การใช้งานจริงและการพัฒนาของเทคโนโลยี ชุมชนนักพัฒนาและผู้ใช้งานได้พบข้อจำกัดและโอกาสในการปรับปรุงหลายประการ

เวอร์ชัน 2.0 ซึ่งได้รับการเผยแพร่เป็น W3C Recommendation อย่างเป็นทางการในช่วงต้นปี 2024 จึงถือเป็นการพัฒนาครั้งสำคัญที่นำเอาบทเรียนจากการใช้งานจริงมาปรับปรุงและขยายขีดความสามารถของมาตรฐาน เป็นการออกแบบใหม่บางส่วนเพื่อรองรับความต้องการที่หลากหลายและซับซ้อนมากขึ้นของระบบ digital identity ในปัจจุบัน

หลักการพื้นฐานของ Verifiable Credentials
ก่อนที่เราจะเข้าสู่การเปรียบเทียบโดยละเอียด ควรเข้าใจหลักการพื้นฐานของ Verifiable Credentials ก่อน ระบบ VC ประกอบด้วยบทบาทหลักสามบทบาท ได้แก่ Issuer ซึ่งเป็นผู้ออก credential เช่น มหาวิทยาลัยที่ออกใบปริญญา Holder ซึ่งเป็นเจ้าของ credential เช่น นักศึกษาที่ได้รับปริญญา และ Verifier ซึ่งเป็นผู้ตรวจสอบ credential เช่น นายจ้างที่ต้องการยืนยันวุฒิการศึกษา
Verifiable Credentials ทำงานบนหลักการที่ว่าข้อมูลประจำตัวควรอยู่ในการควบคุมของเจ้าของข้อมูล และควรสามารถตรวจสอบได้โดยไม่ต้องติดต่อกับผู้ออกทุกครั้ง นี่คือจุดแตกต่างสำคัญจากระบบดั้งเดิมที่ผู้ตรวจสอบต้องโทรศัพท์ไปถามมหาวิทยาลัยทุกครั้งเพื่อยืนยันใบปริญญา ด้วย VC ใบปริญญาจะมีลายเซ็นดิจิทัลที่สามารถตรวจสอบได้ทันทีโดยไม่ต้องรบกวนมหาวิทยาลัย

ความแตกต่างด้านสถาปัตยกรรมและโครงสร้างข้อมูล
การเปลี่ยนแปลงในเรื่อง Context และ JSON-LD
ในเวอร์ชัน 1.1 มาตรฐานได้กำหนดให้การใช้ JSON-LD เป็นสิ่งที่จำเป็นอย่างยิ่ง JSON-LD ย่อมาจาก JSON for Linking Data เป็นรูปแบบข้อมูลที่ขยายความสามารถของ JSON ธรรมดาให้สามารถเชื่อมโยงข้อมูลได้เหมือนกับ Linked Data บนเว็บ การใช้ JSON-LD ใน v1.1 หมายความว่าทุก credential จะต้องมี property ชื่อว่า @context อยู่เสมอ และต้องรวม URL https://www.w3.org/2018/credentials/v1 เป็นค่าแรกใน array ของ context เสมอ
แนวคิดนี้มาจากความต้องการให้ credentials มีความหมายที่ชัดเจนและสามารถตีความได้อย่างเดียวกันในระบบต่างๆ ตัวอย่างเช่น คำว่า "address" อาจหมายถึงที่อยู่ทางไปรษณีย์ หรืออาจหมายถึงที่อยู่อีเมล หรือแม้แต่ address ในระบบ blockchain JSON-LD ช่วยให้เราสามารถกำหนดความหมายที่แน่นอนได้โดยการอ้างอิงไปยัง vocabulary ที่กำหนดไว้
อย่างไรก็ตาม จากการใช้งานจริงพบว่า JSON-LD มีความซับซ้อนสูงสำหรับนักพัฒนาหลายคน โดยเฉพาะผู้ที่ไม่คุ้นเคยกับ Semantic Web Technologies การบังคับใช้ JSON-LD ทำให้เกิดอุปสรรคในการนำ Verifiable Credentials ไปใช้งานในบางสถานการณ์ที่ไม่จำเป็นต้องมีความซับซ้อนระดับนั้น นอกจากนี้ยังมีปัญหาเรื่องขนาดของข้อมูลที่ใหญ่ขึ้นเนื่องจากต้องรวม context ทุกครั้ง
เวอร์ชัน 2.0 จึงมีการปรับเปลี่ยนแนวทางอย่างสำคัญโดยทำให้ JSON-LD เป็นตัวเลือกหนึ่ง ไม่ได้บังคับใช้งาน มาตรฐานใหม่รองรับหลายรูปแบบการเข้ารหัสข้อมูล หรือที่เรียกว่า serialization formats โดยแต่ละรูปแบบมี media type ที่ชัดเจน เช่น application/vc+ld+json สำหรับ JSON-LD, application/vc+jwt สำหรับ JWT และ application/vc+cbor สำหรับ CBOR ซึ่งเป็นรูปแบบไบนารีที่กระชับกว่า
การเปลี่ยนแปลงนี้ให้ความยืดหยุ่นมากขึ้นอย่างมาก นักพัฒนาสามารถเลือกใช้ JSON ธรรมดาเมื่อทำงานในสภาพแวดล้อมที่ต่างๆ หรือเลือกใช้ JSON-LD เมื่อต้องการ interoperability ระดับสูงกับระบบ Semantic Web อื่นๆ นอกจากนี้การรองรับ CBOR ยังเปิดโอกาสให้ใช้งานใน IoT devices หรือ mobile applications ที่มีข้อจำกัดด้าน bandwidth และ storage

การปรับปรุงระบบ Type และ Schema
ระบบการกำหนดประเภทของ credential ใน v1.1 ใช้ property ชื่อว่า type ซึ่งเป็น array ที่ต้องมีค่า "VerifiableCredential" อยู่เสมอ จากนั้นจึงสามารถเพิ่มประเภทอื่นๆ ได้ตามต้องการ ตัวอย่างเช่น credential ที่เป็นใบขับขี่อาจมี type เป็น ["VerifiableCredential", "DriversLicense"] แนวทางนี้ทำงานได้ดี แต่ยังขาดความชัดเจนในเรื่องของ schema validation และการกำหนดว่าแต่ละ type มีโครงสร้างข้อมูลอย่างไร

ใน v2.0 ระบบ type ได้รับการขยายความสามารถให้รองรับการทำงานกับ schema มากขึ้น มีการเพิ่มกลไกสำหรับการอ้างอิงไปยัง schema definitions ที่ชัดเจน ทำให้ verifiers สามารถตรวจสอบได้ว่า credential นั้นมีโครงสร้างข้อมูลที่ถูกต้องตาม type ที่ระบุหรือไม่ นอกจากนี้ยังมีการกำหนด media types ที่ชัดเจนสำหรับแต่ละรูปแบบ credential ซึ่งช่วยให้ระบบสามารถจัดการกับ credentials ต่างรูปแบบได้อย่างเหมาะสม

การมี media types ที่ชัดเจนนี้สำคัญมาก เพราะมันช่วยให้ระบบต่างๆ สามารถเข้าใจได้ทันทีว่า credential นั้นอยู่ในรูปแบบใด และควรประมวลผลอย่างไร เปรียบเหมือนกับไฟล์รูปภาพที่เรามี JPEG, PNG, GIF ซึ่งแต่ละแบบมีวิธีการ decode ที่แตกต่างกัน credential ก็เช่นกัน การมี media type ที่ชัดเจนช่วยให้การ interoperability ดีขึ้นมาก

การเปลี่ยนแปลง Property Names เพื่อความชัดเจน
หนึ่งในการเปลี่ยนแปลงที่สุดใน v2.0 คือการเปลี่ยนชื่อ properties ที่เกี่ยวข้องกับเวลา ใน v1.1 เราใช้ issuanceDate และ expirationDate  แต่จากการใช้งานจริงพบว่าชื่อเหล่านี้อาจทำให้เกิดความสับสนในบางกรณี
คำว่า "issuanceDate" อาจตีความได้ว่าเป็นวันที่ออก credential แต่ไม่ได้บอกชัดเจนว่า credential นั้นใช้งานได้ตั้งแต่เมื่อไร ในบางกรณี credential อาจถูกออกในวันที่หนึ่ง แต่มีผลใช้งานในวันที่สอง เช่น ใบอนุญาตที่ออกล่วงหน้าแต่มีผลใช้งานเมื่อถึงวันที่กำหนด ในทำนองเดียวกัน "expirationDate" บอกว่า credential หมดอายุเมื่อไร แต่ไม่ได้บอกว่ามันหมดอายุในเวลาใดของวันนั้น เช่น เที่ยงคืนหรือเที่ยงวัน

เวอร์ชัน 2.0 จึงเปลี่ยนมาใช้ validFrom และ validUntil แทน ชื่อเหล่านี้ชัดเจนกว่ามากในการบอกว่า credential นี้ใช้ได้ตั้งแต่เมื่อไรจนถึงเมื่อไร นอกจากนี้ยังเพิ่ม property ใหม่ชื่อว่า validityPeriod ที่สามารถใช้กำหนดช่วงเวลาที่ credential มีผลในรูปแบบที่ยืดหยุ่นมากขึ้น

การเปลี่ยนแปลงนี้แม้จะดูเล็กน้อย แต่มีผลกระทบสำคัญต่อการทำงานของระบบ เพราะเวลาเป็นปัจจัยสำคัญในการตรวจสอบความถูกต้องของ credentials การมีชื่อที่ชัดเจนช่วยลดความเสี่ยงของการตีความผิดและการ implement ที่ผิดพลาด อย่างไรก็ตาม การเปลี่ยนชื่อนี้ก็หมายความว่า code ที่เขียนสำหรับ v1.1 จะต้องได้รับการปรับปรุงเพื่อรองรับชื่อใหม่ใน v2.0

การพัฒนาด้านความปลอดภัยและการลงนาม
วิวัฒนาการของ Proof Mechanisms
การพิสูจน์ความถูกต้องของ credentials เป็นหัวใจสำคัญของระบบ Verifiable Credentials เพราะมันคือสิ่งที่ทำให้ credential สามารถ "verify" ได้จริง ใน v1.1 มีการใช้สิ่งที่เรียกว่า Linked Data Proofs หรือ LD Proofs ซึ่งเป็นวิธีการลงนามที่ออกแบบมาสำหรับข้อมูลแบบ JSON-LD โดยเฉพาะ

LD Proofs ทำงานโดยการทำ canonicalization ของข้อมูล JSON-LD ก่อน จากนั้นจึงทำการลงนามด้วย cryptographic signature เช่น RSA หรือ ECDSA วิธีการนี้มีข้อดีคือสามารถลงนามได้โดยไม่เปลี่ยนแปลงโครงสร้างของข้อมูลมากนัก proof จะถูกเพิ่มเข้าไปเป็น property หนึ่งใน credential object

อย่างไรก็ตาม LD Proofs มีความซับซ้อนพอสมควร โดยเฉพาะในเรื่องของ canonicalization algorithm ที่ต้องทำให้ข้อมูล JSON-LD อยู่ในรูปแบบมาตรฐานก่อนที่จะลงนาม นอกจากนี้ การใช้ LD Proofs ยังผูกติดอยู่กับ JSON-LD ทำให้ลำบากเมื่อต้องการใช้รูปแบบข้อมูลอื่น

ใน v2.0 มีการแนะนำ Data Integrity Proofs ซึ่งเป็นการพัฒนาต่อยอดจาก LD Proofs แต่มีความยืดหยุ่นมากกว่า Data Integrity Proofs ออกแบบมาเพื่อทำงานได้กับหลายรูปแบบข้อมูล ไม่จำกัดเฉพาะ JSON-LD มันมี cryptosuite system ที่ชัดเจน ทำให้สามารถรองรับ algorithm ใหม่ๆ ได้ง่ายกว่า

นอกจากนี้ v2.0 ยังปรับปรุงการรองรับ JWT (JSON Web Tokens) ให้ดีขึ้นมาก JWT เป็นมาตรฐานที่ได้รับความนิยมสูงในโลกของ web development และมี library รองรับในเกือบทุกภาษาโปรแกรม ใน v1.1 การใช้ JWT กับ Verifiable Credentials มีความซับซ้อนและไม่ชัดเจนในบางส่วน แต่ v2.0 ได้ทำให้มันเป็นทางเลือกที่ชัดเจนและ well-defined มากขึ้น มีการกำหนด media type เป็น application/vc+jwt และมี specification ที่ชัดเจนว่าควร map ข้อมูลจาก VC data model ไปเป็น JWT claims อย่างไร

การรองรับ Cryptographic Algorithms ที่ทันสมัย
หนึ่งในความก้าวหน้าสำคัญของ v2.0 คือการรองรับ cryptographic algorithms ที่ทันสมัยและมีประสิทธิภาพมากขึ้น ใน v1.1 algorithm หลักที่ได้รับการใช้งานคือ RSA และ ECDSA ซึ่งเป็น algorithms ที่มีมายาวนานและได้รับการพิสูจน์ความปลอดภัยแล้ว

อย่างไรก็ตาม ใน v2.0 มีการเพิ่มการรองรับ EdDSA (Edwards-curve Digital Signature Algorithm) ซึ่งเป็น signature scheme ที่ใช้ elliptic curves แบบใหม่ที่มีประสิทธิภาพและความปลอดภัยสูง EdDSA โดยเฉพาะ Ed25519 กลายเป็นที่นิยมมากในระบบ cryptographic สมัยใหม่เพราะมีความเร็วสูง ใช้ key ขนาดเล็ก และมีความปลอดภัยสูง

ที่สำคัญกว่านั้นคือการรองรับ BBS+ signatures ซึ่งเป็นเทคโนโลยีที่เปลี่ยนเกมในด้าน privacy BBS+ ย่อมาจาก Boneh-Boyen-Shacham scheme ซึ่งเป็น signature scheme ที่รองรับ selective disclosure และ zero-knowledge proofs นี่คือความสามารถที่ผู้ถือ credential สามารถพิสูจน์บางส่วนของข้อมูลโดยไม่ต้องเปิดเผยข้อมูลทั้งหมด

ตัวอย่างเช่น สมมติว่ามี credential ที่มีข้อมูลวันเกิด และต้องการพิสูจน์ว่าคุณมีอายุมากกว่า 18 ปี ด้วย signature แบบธรรมดา จะต้องแสดงข้อมูลวันเกิดทั้งหมด แต่ด้วย BBS+ signatures สามารถพิสูจน์ว่า "มีอายุมากกว่า 18 ปี" โดยไม่ต้องบอกวันเกิดที่แท้จริง นี่คือการปกป้องความเป็นส่วนตัวในระดับสูง

การรองรับ algorithms เหล่านี้ใน v2.0 ไม่ได้หมายความว่า algorithms เก่าจะไม่ถูกใช้อีกต่อไป แต่มันให้ทางเลือกที่หลากหลายขึ้นสำหรับนักพัฒนาในการเลือกใช้ technology ที่เหมาะสมกับ use case ของตนเอง

การจัดการสถานะและการเพิกถอน
ปัญหาของการเพิกถอน Credentials
ในโลกดิจิทัล credential ไม่ควรมีอายุการใช้งานตลอดไปในทุกกรณี บางครั้งต้องมีการเพิกถอนหรือระงับ credential เช่น เมื่อใบขับขี่ถูกระงับชั่วคราว หรือเมื่อพนักงานลาออกจากบริษัทและบัตรพนักงานของเขาควรถูกเพิกถอน ปัญหาคือ หากเราออก credential ให้กับใครสักคนแล้ว credential นั้นก็อยู่ในการครอบครองของเขา เราไม่สามารถไปลบมันออกจากอุปกรณ์ของเขาได้

นี่คือจุดที่ระบบ credential status มีความสำคัญ ผู้ตรวจสอบต้องสามารถเช็คได้ว่า credential ยังคงมีผลหรือถูกเพิกถอนแล้ว แต่การทำเช่นนี้ก็ต้องสมดุลกับความเป็นส่วนตัวด้วย เพราะถ้าทุกครั้งที่มีการตรวจสอบสถานะต้องติดต่อกับ issuer จะทำให้ issuer สามารถ track ได้ว่า credential ถูกใช้งานที่ไหน เมื่อไร

การพัฒนาระบบ Status Checking ใน v2.0
ใน v1.1 มีการกำหนด credentialStatus property ไว้ แต่ไม่ได้ระบุรายละเอียดมากนักว่าควร implement อย่างไร ทำให้แต่ละองค์กรที่ใช้งาน VC ต้องคิดค้น mechanism ของตนเอง ส่งผลให้ขาด interoperability ระหว่างระบบต่างๆ

เวอร์ชัน 2.0 ได้แนะนำ Status List 2021 ซึ่งเป็น mechanism ที่ชาญฉลาดสำหรับการตรวจสอบสถานะแบบ privacy-preserving Status List 2021 ทำงานโดยการสร้าง bitstring ขนาดใหญ่ที่แต่ละ bit แทนสถานะของ credential หนึ่งตัว bitstring นี้ถูก compress และเผยแพร่เป็น credential ตัวหนึ่ง

เมื่อต้องการตรวจสอบสถานะของ credential ผู้ตรวจสอบจะ download status list credential นี้มา decompress และเช็ค bit ที่ตำแหน่งที่กำหนด หาก bit เป็น 1 แสดงว่า credential ถูกเพิกถอน หากเป็น 0 แสดงว่ายังใช้งานได้ วิธีนี้มีข้อดีหลายประการ
ประการแรก มันมีประสิทธิภาพสูง เพราะ status list เดียวสามารถเก็บสถานะของ credentials หลายแสนหรือหลายล้านตัวได้ ประการที่สอง มันช่วยรักษาความเป็นส่วนตัว เพราะการ download status list ไม่ได้บอก issuer ว่าเรากำลังเช็ค credential ไหน ทุกคนที่ download status list เดียวกันจะได้ข้อมูลเหมือนกัน ทำให้ไม่สามารถ track individual usage ได้
นอกจากนี้ v2.0 ยังรองรับหลาย status types เช่น revocation (เพิกถอนถาวร) และ suspension (ระงับชั่วคราว) credential อาจถูกระงับเพราะเหตุผลบางอย่างแต่อาจกลับมาใช้งานได้อีก ซึ่งต่างจากการเพิกถอนที่เป็นการถาวร

ความเป็นส่วนตัวและการปกป้องข้อมูลส่วนบุคคล
ปัญหาความเป็นส่วนตัวในระบบ Digital Identity
ความเป็นส่วนตัวเป็นหนึ่งในความท้าทายใหญ่ที่สุดของระบบ digital identity ในปัจจุบัน ระบบดั้งเดิมมักต้องการให้ผู้ใช้เปิดเผยข้อมูลมากกว่าที่จำเป็น ตัวอย่างเช่น เมื่อซื้อเครื่องดื่มแอลกอฮอล์ ร้านค้าต้องการยืนยันว่าลูกค้ามีอายุมากกว่า 20 ปี แต่ต้องแสดงบัตรประชาชนที่มีข้อมูลเต็มรูปแบบ รวมถึงชื่อ-นามสกุล ที่อยู่ วันเกิดที่แท้จริง และอื่นๆ อีกมากมาย

นอกจากนี้ยังมีปัญหาของ correlation คือการที่หลายองค์กรสามารถเชื่อมโยงข้อมูลการใช้งานของบุคคลเดียวกันได้โดยใช้ identifier ที่ซ้ำกัน เช่น เลขบัตรประชาชน หากบริษัท A, B, และ C ทั้งหมดเก็บเลขบัตรประชาชน พวกเขาอาจสามารถแบ่งปันหรือซื้อขายข้อมูลและเชื่อมโยงกิจกรรมข้ามแพลตฟอร์มได้

Selective Disclosure ในเวอร์ชัน 2.0
Selective Disclosure คือความสามารถในการเปิดเผยเฉพาะข้อมูลบางส่วนที่จำเป็นเท่านั้น โดยไม่ต้องแสดงข้อมูลทั้งหมด ใน v1.1 การทำ selective disclosure มีความซับซ้อนและไม่ได้เป็นส่วนหนึ่งของ core specification ผู้พัฒนาที่ต้องการฟีเจอร์นี้ต้องใช้วิธีการพิเศษหรือ extensions ต่างๆ

เวอร์ชัน 2.0 ได้นำ selective disclosure มาเป็นส่วนหนึ่งของมาตรฐานอย่างเป็นทางการ โดยเฉพาะผ่านการรองรับ BBS+ signatures ที่กล่าวไปแล้ว ด้วย BBS+ ผู้ออก credential สามารถลงนามข้อมูลหลายๆ ส่วนแยกกัน และผู้ถือ credential สามารถเลือกเปิดเผยเฉพาะส่วนที่ต้องการได้

ตัวอย่างการใช้งานจริง สมมติว่าบัตรประจำตัวนักศึกษา ที่มีข้อมูล: ชื่อนักศึกษา, หลักสูตร, GPA, วันจบการศึกษา, และเลขประจำตัวนักศึกษา เมื่อสมัครงานบางตำแหน่งอาจต้องการเพียง หลักสูตรและวันจบการศึกษา ผู้สมัครสามารถสร้าง presentation ที่แสดงเฉพาะข้อมูลสองส่วนนี้ โดยไม่เปิดเผย GPA หรือเลขประจำตัวนักศึกษา และผู้ตรวจสอบยังสามารถยืนยันได้ว่าข้อมูลที่ผู้สมัครแสดงนั้นถูกต้องและมาจากมหาวิทยาลัยจริง

Zero-Knowledge Proofs และการประยุกต์ใช้
Zero-Knowledge Proofs (ZKP) เป็นเทคโนโลยีที่ก้าวล้ำซึ่งช่วยให้สามารถพิสูจน์คำกล่าวอ้างบางอย่างเป็นความจริงโดยไม่ต้องเปิดเผยข้อมูลเบื้องหลัง ใน v2.0 การรองรับ BBS+ signatures เปิดโอกาสให้ใช้ ZKP ได้อย่างเต็มที่

ตัวอย่างที่น่าสนใจคือการพิสูจน์ช่วงของตัวเลข (range proofs) โดยหลักการสามารถพิสูจน์ว่า เช่น "เงินเดือนของฉันอยู่ระหว่าง 50,000-100,000 บาท" โดยไม่ต้องบอกว่าเงินเดือนแท้จริงคือเท่าไร หรือพิสูจน์ว่า "ฉันอายุมากกว่า 18 แต่น้อยกว่า 65" โดยไม่ต้องบอกอายุที่แน่นอน

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

เทคโนโลยีเหล่านี้ยังอยู่ในช่วงเริ่มต้นและมีความซับซ้อนในการ implement แต่ v2.0 ได้เตรียมรากฐานไว้สำหรับการนำไปใช้งานในอนาคต ซึ่งจะช่วยยกระดับการปกป้องความเป็นส่วนตัวในระบบ digital identity ไปอีกขั้น

การจัดการ Identifiers และ DIDs Decentralized Identifiers ในระบบ Verifiable Credentials
Decentralized Identifiers หรือ DIDs เป็นมาตรฐานของ W3C สำหรับ identifier แบบกระจายอำนาจที่ไม่ต้องพึ่งพา centralized authority DIDs มีบทบาทสำคัญในระบบ Verifiable Credentials เพราะมันช่วยให้ issuers, holders, และ verifiers สามารถมี identifier ที่พวกเขาควบคุมเองได้อย่างเต็มที่
ใน v1.1 การใช้ DIDs เป็นทางเลือกหนึ่ง credentials อาจใช้ URLs หรือ URIs ธรรมดาก็ได้ แต่การรองรับ DIDs ยังไม่สมบูรณ์และขาดรายละเอียดในบางส่วน ทำให้ผู้พัฒนาต้องตีความเองว่าควร integrate DIDs อย่างไร

การปรับปรุง DID Integration ใน v2.0
เวอร์ชัน 2.0 ให้ความสำคัญกับ DIDs มากขึ้น โดยมีการปรับปรุงหลายประการ ประการแรกคือ DID Resolution process ที่ชัดเจนขึ้น DID Resolution คือกระบวนการที่เราใช้ DID เพื่อหา DID Document ซึ่งเป็นเอกสารที่บรรจุข้อมูลเกี่ยวกับ DID นั้น เช่น public keys, service endpoints, และอื่นๆ

ใน v2.0 มีการกำหนดชัดเจนว่าเมื่อเจอ DID ใน credential ควร resolve มันอย่างไรและจะทำอะไรกับข้อมูลที่ได้ นอกจากนี้ยังมีการรองรับ DID methods ต่างๆ ได้ดีขึ้น DID methods เปรียบเหมือน "ภาษาถิ่น" ของ DIDs โดยแต่ละ method มีวิธีการสร้าง resolve และจัดการ DIDs ที่แตกต่างกัน

ตัวอย่าง DID methods ที่ได้รับความนิยม เช่น did:web ซึ่งใช้ web infrastructure ที่มีอยู่, did:key ซึ่งเป็น DID แบบง่ายที่ derive มาจาก public key โดยตรง, หรือ did:ethr ซึ่งใช้ Ethereum blockchain เป็นที่เก็บข้อมูล v2.0 ให้แนวทางที่ชัดเจนว่าควรจัดการ DID methods ต่างๆ เหล่านี้อย่างไร

Holder Binding และการพิสูจน์การเป็นเจ้าของ
Holder Binding เป็นกลไกที่ผูก credential เข้ากับผู้ถือที่ถูกต้อง เพื่อป้องกันไม่ให้คนอื่นนำ credential ที่ถูกขโมยหรือคัดลอกไปใช้ ใน v1.1 มี concept นี้อยู่แต่ไม่ได้ standardize มากนัก
เวอร์ชัน 2.0 แนะนำหลายวิธีในการทำ holder binding ที่ชัดเจนขึ้น วิธีหนึ่งคือการใส่ DID ของ holder ไว้ใน credentialSubject และเมื่อนำเสนอ credential ผู้ถือต้องพิสูจน์ว่าเขาควบคุม private key ของ DID นั้นจริง โดยการลงนามใน presentation

อีกวิธีหนึ่งคือการใช้ biometric binding ซึ่ง credential อาจมีข้อมูล biometric template และเมื่อนำเสนอต้องพิสูจน์ด้วย biometric จริง แม้ว่าวิธีนี้จะยังมีความท้าทายด้านเทคนิคและความเป็นส่วนตัว แต่ v2.0 ได้เตรียมกรอบไว้สำหรับการพัฒนาในอนาคต

ฟีเจอร์ใหม่ที่เพิ่มเข้ามาใน v2.0
Evidence: การแนบหลักฐานประกอบ
Property ใหม่ที่สำคัญใน v2.0 คือ evidence ซึ่งช่วยให้ issuer สามารถแนบข้อมูลเกี่ยวกับหลักฐานที่ใช้ในการออก credential ได้ ตัวอย่างเช่น เมื่อธนาคารออก credential ยืนยันตัวตน พวกเขาอาจแนบข้อมูลว่าได้ทำการ KYC (Know Your Customer) อย่างไร มีการตรวจสอบเอกสารใดบ้าง หรือมีการยืนยันด้วย biometric หรือไม่
Evidence ไม่ได้หมายความว่าต้องแนบเอกสารต้นฉบับทั้งหมด (ซึ่งอาจละเมิดความเป็นส่วนตัว) แต่เป็นการให้ metadata หรือ reference ที่อธิบายว่ามีการตรวจสอบอย่างไร ทำให้ verifier สามารถประเมินระดับความน่าเชื่อถือของ credential ได้ดีขึ้น
ตัวอย่าง evidence structure อาจมีหน้าตาแบบนี้:
json
"evidence": [{
  "type": "DocumentVerification",
  "verifier": "did:example:issuer",
  "evidenceDocument": "passport",
  "subjectPresence": "Physical",
  "documentPresence": "Physical"
}]
การมี evidence ช่วยเพิ่มความโปร่งใสและช่วยให้ verifiers สามารถตัดสินใจได้อย่างมีข้อมูล โดยเฉพาะในกรณีที่ต้องการระดับความมั่นใจสูง เช่น การทำธุรกรรมทางการเงินขนาดใหญ่
Confidence Method: การประเมินความเชื่อมั่น
confidenceMethod เป็น property ใหม่ที่ช่วยให้ระบุวิธีการประเมินความเชื่อมั่นหรือความน่าเชื่อถือของ credential ในโลกจริง ไม่ใช่ทุก credential ที่มีระดับความน่าเชื่อถือเท่ากัน credential บางตัวอาจผ่านกระบวนการตรวจสอบที่เข้มงวด ในขณะที่บางตัวอาจเป็นเพียงการยืนยันตัวเองโดยผู้ใช้
Confidence method ช่วยให้ verifiers สามารถประเมินได้ว่า credential นี้มีความน่าเชื่อถือในระดับใด และเหมาะสมกับ use case ของพวกเขาหรือไม่ ตัวอย่างเช่น การซื้อของออนไลน์อาจยอมรับ credential ที่มีความน่าเชื่อถือปานกลาง แต่การเปิดบัญชีธนาคารอาจต้องการ credential ที่ผ่านการตรวจสอบระดับสูง
Render Method: การควบคุมการแสดงผล
Property renderMethod เป็นนวัตกรรมที่น่าสนใจใน v2.0 มันช่วยให้ issuers สามารถกำหนดวิธีการแสดงผล credential ได้ นี่เป็นสิ่งสำคัญเพราะ credentials อาจถูกแสดงในหลายรูปแบบ - บนมือถือ, บนเว็บ, หรือแม้แต่ในรูปแบบการพิมพ์
Render method อาจระบุ template สำหรับการแสดงผล รวมถึงกำหนด visual style, layout, และแม้แต่ภาษาที่ใช้แสดงผล การมีมาตรฐานนี้ช่วยให้ credentials มี user experience ที่ดีและสม่ำเสมอในทุก platform
ตัวอย่างเช่น credential ที่เป็นใบรับรองทางการแพทย์อาจมี render method ที่กำหนดให้แสดงข้อมูลสำคัญเด่นชัด แสดงโลโก้ของโรงพยาบาล และใช้สีที่เหมาะสมกับบริบททางการแพทย์ ในขณะที่ credential ที่เป็นตั๋วคอนเสิร์ตอาจมี render method ที่เน้นด้านความสนุกสนานและใช้สีสันสดใส
ระบบ Internationalization ที่ดีขึ้น
การรองรับหลายภาษาเป็นสิ่งสำคัญในโลกที่มีความหลากหลาย v1.1 มีการรองรับ multilingual content ผ่าน JSON-LD แต่มีความซับซ้อนและไม่ชัดเจนในบางกรณี
เวอร์ชัน 2.0 ปรับปรุงระบบ i18n (internationalization) ให้ง่ายและยืดหยุ่นขึ้น มีแนวทางที่ชัดเจนสำหรับการกำหนด display properties ในหลายภาษา เช่น ชื่อของ credential type หรือ description ของ fields ต่างๆ
ตัวอย่างการใช้งาน credential อาจมีชื่อเป็นภาษาไทยว่า "ใบรับรองการศึกษา" และภาษาอังกฤษว่า "Education Certificate" พร้อมกัน และระบบจะเลือกแสดงภาษาที่เหมาะสมตาม locale ของผู้ใช้โดยอัตโนมัติ
นอกจากนี้ยังรองรับการกำหนด text direction สำหรับภาษาที่เขียนจากขวาไปซ้าย เช่น ภาษาอาหรับและภาษาฮิบรู และการจัดการ date/time formats ที่แตกต่างกันในแต่ละ locale
 
การเปลี่ยนแปลงในด้านเทคนิคและ Implementation
Serialization Formats และ Media Types
หนึ่งในการเปลี่ยนแปลงพื้นฐานที่สุดใน v2.0 คือการรองรับหลาย serialization formats อย่างเป็นทางการ ใน v1.1 แม้ว่าจะสามารถใช้รูปแบบต่างๆ ได้ แต่ไม่มีการกำหนดที่ชัดเจน ทำให้เกิดความสับสนและปัญหา interoperability
เวอร์ชัน 2.0 กำหนด media types อย่างชัดเจนสำหรับแต่ละรูปแบบ:

• application/vc+ld+json สำหรับ JSON-LD credentials
• application/vc+jwt สำหรับ JWT-based credentials
• application/vc+cbor สำหรับ CBOR-encoded credentials
• application/vp+ld+json สำหรับ JSON-LD presentations
• และอื่นๆ

การมี media types เหล่านี้ช่วยให้ระบบสามารถ negotiate กันได้ว่าควรใช้รูปแบบใด เช่น mobile application อาจขอ CBOR เพราะกระชับกว่า ในขณะที่ web application อาจขอ JSON-LD เพราะง่ายต่อการจัดการใน JavaScript
นอกจากนี้ยังมีการกำหนดว่าแต่ละ media type ควรมี structure อย่างไร เช่น JWT-based credentials ต้อง map ข้อมูลจาก data model ไปเป็น JWT claims อย่างไร ควรใช้ header parameters ใดบ้าง และอื่นๆ ความชัดเจนนี้ช่วยลด ambiguity และทำให้ implementations จากผู้พัฒนาต่างคนสามารถทำงานร่วมกันได้
CBOR: Concise Binary Object Representation
CBOR เป็น binary data format ที่ออกแบบมาเพื่อความกระชับและประสิทธิภาพ มันคล้ายกับ JSON ในแง่ของ data model แต่ใช้ binary encoding แทน text จึงมีขนาดเล็กกว่าและ parse เร็วกว่า
การรองรับ CBOR ใน v2.0 เปิดโอกาสใหม่สำหรับ use cases หลายอย่าง เช่น:

• IoT devices: อุปกรณ์ IoT มักมีหน่วยความจำจำกัดและต้องการประหยัด bandwidth CBOR ช่วยให้ credentials มีขนาดเล็กลง
• Mobile applications: การลดขนาดข้อมูลช่วยประหยัดแบตเตอรี่และ network usage
• Offline scenarios: CBOR มี features สำหรับ streaming และ incremental parsing ที่เหมาะกับสถานการณ์ที่มี connectivity จำกัด

CBOR ยังมี CBOR Web Tokens (CWT) ซึ่งเป็นเหมือน JWT แต่ใช้ CBOR แทน JSON ทำให้เหมาะสำหรับ constrained environments
Canonicalization และ Hashing
Canonicalization คือกระบวนการแปลงข้อมูลให้อยู่ในรูปแบบมาตรฐานเดียว นี่เป็นสิ่งสำคัญสำหรับการลงนามและการตรวจสอบความถูกต้อง เพราะข้อมูล JSON เดียวกันอาจเขียนในหลายรูปแบบได้ (เช่น ลำดับของ properties อาจต่างกัน, whitespace อาจต่างกัน)
ใน v1.1 ใช้ JSON-LD canonicalization algorithm ซึ่งมีความซับซ้อนสูง v2.0 ปรับปรุงเรื่องนี้โดยมีหลาย options:

• สำหรับ JSON-LD ยังคงใช้ canonicalization algorithm ที่ปรับปรุงแล้ว
• สำหรับ JWT ใช้วิธีการ standard ของ JWT ที่ sign ทั้ง header และ payload
• สำหรับ CBOR มี deterministic encoding ที่ทำให้ representation เป็น canonical โดยธรรมชาติ

การมีหลาย options นี้ให้ความยืดหยุ่น แต่ก็ต้องระวังเรื่อง interoperability ระหว่างระบบที่ใช้ canonicalization methods ต่างกัน
การเปลี่ยนแปลงใน Presentation และ Verification
Verifiable Presentations: การนำเสนอ Credentials
Verifiable Presentation คือสิ่งที่ holder สร้างขึ้นเพื่อนำเสนอ credentials ไปยัง verifier มันอาจประกอบด้วย credentials หนึ่งหรือหลายตัว พร้อมกับข้อมูลเพิ่มเติมและการลงนามของ holder
ใน v1.1 presentations มีโครงสร้างพื้นฐานแต่ขาดรายละเอียดในบางเรื่อง เช่น การจัดการกับ credentials หลายตัวที่มาจาก issuers ต่างกัน หรือการรวม credentials กับ self-attested claims
เวอร์ชัน 2.0 ขยายความสามารถของ presentations หลายด้าน รองรับการรวม credentials จากหลาย issuers ในแบบที่มีโครงสร้างชัดเจน มีกลไกสำหรับ holder binding ที่ดีขึ้น และรองรับ challenge-response protocol ที่ป้องกัน replay attacks
Replay attack คือการที่ผู้ไม่หวังดีดัก presentation ที่ถูกต้องมาแล้วนำไปใช้ซ้ำในภายหลัง การใช้ challenge-response ทำให้แต่ละ presentation ถูกสร้างขึ้นเพื่อตอบ challenge เฉพาะที่ verifier ส่งมา จึงไม่สามารถนำไปใช้ซ้ำได้
Presentation Exchange Protocol
Presentation Exchange เป็น protocol ที่กำหนดว่า verifiers และ holders ควรสื่อสารกันอย่างไรในกระบวนการขอและส่ง credentials แม้ว่า Presentation Exchange จะเป็น specification แยกต่างหาก แต่ v2.0 ของ VC Data Model ได้ออกแบบมาเพื่อรองรับมันได้ดีขึ้น
Presentation Exchange ทำงานโดยให้ verifier ส่ง Presentation Definition ซึ่งอธิบายว่าต้องการ credentials ประเภทใด มี properties อะไรบ้าง และมีเงื่อนไขอย่างไร จากนั้น holder จะสร้าง Presentation Submission ที่ตรงตามความต้องการนั้น
ตัวอย่าง Presentation Definition อาจระบุว่า "ฉันต้องการ credential ที่แสดงว่าคุณมีอายุมากกว่า 18 ปี หรือ credential ที่แสดงว่าคุณเป็นสมาชิกของมหาวิทยาลัยที่ได้รับการรับรอง" Holder สามารถเลือกว่าจะใช้ credential ใดในการตอบสนอง
การรองรับ Presentation Exchange ช่วยให้เกิด interoperability ระหว่าง wallet applications ต่างๆ ได้ดี เพราะทุกคนใช้ protocol เดียวกันในการขอและส่งข้อมูล
Verification Process และ Trust Frameworks
กระบวนการ verification ใน v2.0 มีความซับซ้อนและครอบคลุมมากขึ้น การตรวจสอบไม่ได้จำกัดอยู่แค่การเช็ค cryptographic signature แต่ยังรวมถึง:

1. Credential Integrity: ตรวจสอบว่า credential ไม่ถูกแก้ไข
2. Issuer Verification: ยืนยันว่า issuer เป็นใคร และน่าเชื่อถือหรือไม่
3. Status Checking: เช็คว่า credential ยังไม่ถูกเพิกถอน
4. Validity Period: ตรวจสอบว่า credential ยังไม่หมดอายุ
5. Holder Binding: ยืนยันว่าผู้นำเสนอเป็นเจ้าของ credential จริง
6. Context Verification: ตรวจสอบว่า credential เหมาะสมกับบริบทของการใช้งาน

Trust Frameworks เป็นกรอบที่กำหนดว่าใครน่าเชื่อถือในระบบ และด้วยเหตุผลใด ใน v2.0 มีการรองรับ trust frameworks ได้ดีขึ้นผ่าน properties ต่างๆ เช่น termsOfUse ที่ระบุเงื่อนไขการใช้งาน credential หรือการอ้างอิงไปยัง trust registry ที่เก็บรายชื่อ issuers ที่ได้รับการรับรอง
Use Cases และการประยุกต์ใช้งาน
Education Sector: การศึกษา
ภาคการศึกษาเป็นหนึ่งใน use cases ที่สำคัญของ Verifiable Credentials มหาวิทยาลัยสามารถออก digital diplomas ที่นักศึกษาสามารถเก็บไว้และนำเสนอได้ตลอดชีวิต โดยไม่ต้องกังวลว่ามหาวิทยาลัยจะปิดตัวหรือเปลี่ยนระบบ
ด้วย v2.0 ความสามารถใหม่ๆ ทำให้ use case นี้ดีขึ้น:

• Selective Disclosure: นักศึกษาสามารถแสดงเฉพาะข้อมูลที่จำเป็น เช่น แสดงว่าจบปริญญาตรีสาขาคอมพิวเตอร์ โดยไม่ต้องเปิดเผย GPA
• International Recognition: การใช้ DID และมาตรฐานสากลทำให้ credentials ถูกยอมรับข้ามประเทศได้ดีขึ้น
• Evidence: มหาวิทยาลัยสามารถแนบข้อมูลการตรวจสอบตัวตนของนักศึกษาในขณะสมัคร เพิ่มความน่าเชื่อถือ

Healthcare: การแพทย์และสาธารณสุข
ภาคการแพทย์เป็นอีก sector ที่ได้ประโยชน์อย่างมากจาก Verifiable Credentials เวชระเบียน ใบรับรองการฉีดวัคซีน ใบอนุญาตประกอบวิชาชีพแพทย์ หรือผลตรวจทางการแพทย์ ล้วนสามารถเป็น credentials ได้
V2.0 นำเสนอความสามารถที่สำคัญสำหรับ healthcare:

• Privacy Protection: ข้อมูลสุขภาพเป็นข้อมูลที่ละเอียดอ่อนมาก การใช้ selective disclosure และ ZKP ช่วยปกป้องความเป็นส่วนตัว เช่น พิสูจน์ว่า "ฉันได้รับวัคซีนครบแล้ว" โดยไม่ต้องเปิดเผยประวัติการแพ้ยาหรือโรคประจำตัว
• Emergency Access: มี mechanisms สำหรับการเข้าถึงข้อมูลฉุกเฉิน โดยมีการควบคุมและ audit trail ที่ชัดเจน
• Cross-border Health Data: ผู้ป่วยสามารถนำเวชระเบียนของตนไปใช้ในต่างประเทศได้โดยไม่ต้องพึ่งพา centralized database
• Clinical Trials: การใช้ verifiable credentials ในการจัดการข้อมูลผู้เข้าร่วมการทดลองทางคลินิกช่วยเพิ่มความปลอดภัยและความน่าเชื่อถือของข้อมูล

Financial Services: บริการทางการเงิน
สถาบันการเงินต้องการความมั่นใจสูงในการยืนยันตัวตนของลูกค้า Verifiable Credentials สามารถปรับปรุงกระบวนการ KYC (Know Your Customer) ให้มีประสิทธิภาพมากขึ้น
ความสามารถใหม่ใน v2.0 ที่เป็นประโยชน์:

• Reusable KYC: ลูกค้าทำ KYC กับสถาบันหนึ่งครั้งเดียว แล้วสามารถใช้ credential นั้นกับสถาบันอื่นได้ โดยไม่ต้องผ่านกระบวนการซ้ำซาก
• Risk Assessment: การมี confidence method และ evidence ช่วยให้สถาบันการเงินประเมินความเสี่ยงได้ดีขึ้น
• AML Compliance: สามารถแชร์ข้อมูล Anti-Money Laundering ระหว่างสถาบันได้โดยไม่ละเมิดความเป็นส่วนตัว
• Credit Scores: คะแนนเครดิตสามารถเป็น verifiable credential ที่ลูกค้าควบคุมเองได้

Government Services: บริการภาครัฐ
รัฐบาลหลายประเทศกำลังสำรวจการใช้ Verifiable Credentials สำหรับ digital identity ของประชาชน รวมถึงใบอนุญาตต่างๆ เช่น ใบขับขี่ ทะเบียนบ้าน หรือเอกสารภาษี
V2.0 รองรับ government use cases ดังนี้:

• National ID Systems: สามารถออก digital national ID ที่มีความปลอดภัยสูงและป้องกันการปลอมแปลง
• Age Verification: พลเมืองสามารถพิสูจน์อายุโดยไม่ต้องเปิดเผยวันเกิดที่แน่นอน ซึ่งสำคัญสำหรับการซื้อสินค้าที่จำกัดอายุ
• Voting Systems: แม้ว่าจะมีความท้าทาย แต่ verifiable credentials สามารถใช้เป็นส่วนหนึ่งของระบบ e-voting ที่ปลอดภัย
• Border Control: immigration credentials ที่ตรวจสอบได้ทำให้การผ่านด่านตรวจคนเข้าเมืองรวดเร็วและปลอดภัยขึ้น

Supply Chain และ Product Authenticity
อุตสาหกรรม supply chain ใช้ Verifiable Credentials เพื่อตรวจสอบความถูกต้องของสินค้าและการเดินทางของผลิตภัณฑ์
การประยุกต์ใช้:

• Product Passports: แต่ละผลิตภัณฑ์มี credential ที่บอกที่มา วัตถุดิบ และประวัติการผลิต
• Ethical Sourcing: พิสูจน์ว่าสินค้ามาจากแหล่งที่ยุติธรรมและเป็นมิตรกับสิ่งแวดล้อม
• Anti-counterfeiting: ป้องกันสินค้าปลอมด้วยการตรวจสอบ credentials ที่ผู้ผลิตแท้เท่านั้นที่สามารถออกได้
• Recall Management: เมื่อต้องเรียกสินค้าคืน สามารถระบุและติดตามผลิตภัณฑ์ที่มีปัญหาได้อย่างแม่นยำ

ความท้าทายในการ Migration จาก v1.1 ไป v2.0
Breaking Changes และ Backward Compatibility
การอัปเกรดจาก v1.1 ไป v2.0 ไม่ใช่เรื่องง่าย เพราะมี breaking changes หลายประการ การเปลี่ยนชื่อ properties เช่น issuanceDate เป็น validFrom หมายความว่า code ที่เขียนสำหรับ v1.1 จะไม่ทำงานกับ credentials ในรูปแบบ v2.0 โดยตรง
องค์กรที่กำลังพิจารณา migration ควรพิจารณา:
แนวทาง Transition เพื่อรองรับทั้ง v1.1 และ v2.0 ไปพร้อมกันในช่วงเปลี่ยนผ่าน ระบบสามารถอ่านได้ทั้งสองเวอร์ชัน และออก credentials ในรูปแบบที่รองรับทั้งสองเวอร์ชันหรือเลือกออกตามความสามารถของผู้รับ
Gradual Rollout: ไม่จำเป็นต้องเปลี่ยนทันทีทั้งระบบ เริ่มจากการรองรับ v2.0 ในส่วนใหม่ๆ และค่อยๆ migrate ส่วนเก่าทีละส่วน
Testing และ Interoperability: ทดสอบอย่างละเอียดกับระบบอื่นๆ ที่ต้องทำงานด้วย เพราะอาจมีการตีความมาตรฐานที่แตกต่างกัน
เรื่องของ Tooling และ Libraries
Libraries และ tools สำหรับ Verifiable Credentials จำนวนมากถูกพัฒนาสำหรับ v1.1 การอัปเกรดเป็น v2.0 หมายความว่าต้องรอให้ libraries เหล่านั้นอัปเดตด้วย หรืออาจต้องสลับไปใช้ libraries ใหม่
ประเด็นที่ต้องพิจารณา:

• Library Maturity: Libraries สำหรับ v2.0 อาจยังไม่เสถียรหรือมีฟีเจอร์ไม่ครบเท่า v1.1
• Community Support: ชุมชนนักพัฒนาอาจยังไม่คุ้นเคยกับ v2.0 ทำให้หาคำตอบหรือความช่วยเหลือได้ยากกว่า
• Documentation: เอกสารและ tutorials สำหรับ v2.0 อาจยังไม่มากเท่า v1.1
• Vendor Support: ถ้าใช้ third-party services หรือ platforms ต้องตรวจสอบว่าพวกเขารองรับ v2.0 แล้วหรือยัง

ผลกระทบต่อ Ecosystem และอนาคต
การยอมรับและการนำไปใช้งาน
แม้ว่า v2.0 จะมีความสามารถที่ดีกว่า แต่การยอมรับใช้เวลา v1.1 ถูกใช้งานจริงในหลายระบบแล้ว และการเปลี่ยนแปลงใหญ่ๆ ย่อมเกิดความเฉื่อย (inertia) องค์กรที่ลงทุนไปมากใน v1.1 อาจลังเลที่จะเปลี่ยน
อย่างไรก็ตาม มีปัจจัยหลายอย่างที่จะผลักดัน adoption ของ v2.0:
Government Initiatives: รัฐบาลหลายประเทศกำลังพัฒนา national digital identity programs และอาจเลือกใช้เทคโนโลยีล่าสุด
Industry Standards: องค์กรมาตรฐานต่างๆ เช่น ISO กำลังพัฒนามาตรฐานที่อ้างอิงถึง v2.0
Vendor Competition: บริษัทที่ให้บริการ identity platforms จะแข่งขันกันโดยการนำเสนอฟีเจอร์ล่าสุด
Privacy Regulations: กฎหมายเช่น GDPR ที่เน้นการปกป้องข้อมูลส่วนบุคคลทำให้ฟีเจอร์ privacy-enhancing ใน v2.0 มีความสำคัญมากขึ้น

ตารางสรุปรายละเอียดการเปรียบเทียบ VCDM v1.1 และ v2.0
ด้านโครงสร้าง

ลักษณะ	v1.1	v2.0	ผลกระทบ
JSON-LD Requirement	บังคับ	ทางเลือก	เพิ่มความยืดหยุ่น ลดอุปสรรคในการนำไปใช้
Media Types	ไม่ชัดเจน	กำหนดชัดเจน	ปรับปรุง content negotiation
CBOR Support	ไม่มี	รองรับ	เหมาะกับ IoT และ mobile
Context Flexibility	จำกัด	สูง	รองรับ use cases หลากหลาย

 
ด้านความปลอดภัยและการลงนาม

ลักษณะ	v1.1	v2.0	ผลกระทบ
Proof Type	Linked Data Proofs	Data Integrity Proofs	ยืดหยุ่นและทันสมัยขึ้น
JWT Support	จำกัด	เต็มรูปแบบ	ใช้งานง่ายกับระบบที่มีอยู่
BBS+ Signatures	ไม่รองรับ	รองรับ	เปิดใช้งาน selective disclosure
EdDSA	ไม่รองรับ	รองรับ	ประสิทธิภาพและความปลอดภัยสูง

 
 
ด้าน Properties และข้อมูล

Property	v1.1	v2.0	เหตุผลการเปลี่ยน
Issuance Date	issuanceDate	validFrom	ความชัดเจนของความหมาย
Expiration	expirationDate	validUntil	สอดคล้องกับ validFrom
Evidence	ไม่มี	มี	เพิ่มความโปร่งใส
Confidence Method	ไม่มี	มี	ประเมินความน่าเชื่อถือ
Render Method	ไม่มี	มี	ควบคุมการแสดงผล

 
ด้านการจัดการสถานะ

ด้าน	v1.1	v2.0	การปรับปรุง
Status Mechanism	พื้นฐาน	Status List 2021	มีประสิทธิภาพและรักษาความเป็นส่วนตัว
Revocation Types	จำกัด	หลากหลาย	รองรับทั้ง revocation และ suspension
Batch Checking	ไม่มี	รองรับ	ตรวจสอบได้เร็วขึ้น
Privacy	อ่อน	ดีขึ้น	ไม่เปิดเผยการใช้งานรายบุคคล

 คำแนะนำสำหรับองค์กรที่กำลังตัดสินใจ
เมื่อไหร่ควรใช้ v1.1
แม้ว่า v2.0 จะมีความสามารถมากกว่า แต่ยังมีสถานการณ์ที่การใช้ v1.1 อาจเหมาะสมกว่า:
โปรเจกต์ระยะสั้น: หากต้องการ deploy เร็วและใช้งานระยะสั้น การใช้ v1.1 ที่มี tooling ครบถ้วนแล้วอาจเป็นทางเลือกที่ดี
Ecosystem ที่มีอยู่: หากต้องทำงานกับระบบที่ใช้ v1.1 อยู่แล้วและไม่มีแผนอัปเกรด การใช้ v1.1 ช่วยลดความซับซ้อน
Simple Use Cases: สำหรับ use cases ที่ไม่ต้องการฟีเจอร์ขั้นสูงเช่น selective disclosure หรือ ZKP, v1.1 อาจเพียงพอ
Team Expertise: หากทีมมีความเชี่ยวชาญใน v1.1 แล้วและไม่มีเวลาเรียนรู้เทคโนโลยีใหม่
เมื่อไหร่ควรใช้ v2.0
V2.0 ควรเป็นทางเลือกสำหรับ:
โปรเจกต์ใหม่ระยะยาว: การลงทุนใน v2.0 ตั้งแต่เริ่มต้นจะประหยัดความพยายามในการ migrate ภายหลัง
Privacy-Sensitive Applications: เมื่อความเป็นส่วนตัวเป็นความต้องการสำคัญ ฟีเจอร์ใน v2.0 มีคุณค่ามาก
Mobile และ IoT: การรองรับ CBOR และ lightweight formats ทำให้เหมาะกับ constrained environments
Innovative Use Cases: เมื่อต้องการทดลองเทคโนโลยีใหม่หรือสร้าง competitive advantage
International Interoperability: V2.0 มีมาตรฐานที่ชัดเจนกว่าสำหรับการทำงานข้ามระบบ