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

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

ผู้ขับขี่คนเดียว สิทธิ์ในการขับขี่เดียว กระเป๋าเงินดิจิทัลใบเดียว แต่มีผู้ตรวจสอบที่แตกต่างกันถึงสี่ประเภท:

• เจ้าหน้าที่ตำรวจริมถนน
• เคาน์เตอร์เช่ารถเมื่อรับรถ
• นายจ้างที่ตรวจสอบคุณสมบัติการใช้ยานพาหนะขององค์กร
• บริษัทประกันที่พิจารณาการเรียกร้องสินไหม

หาก IDP ในอนาคตแสดงข้อมูลชุดเดียวกันแก่ทั้งสี่ฝ่าย ระบบนั้นก็ล้มเหลวตั้งแต่ต้น ไม่ใช่เพราะข้อมูลรับรองไม่ปลอดภัย แต่เพราะโมเดลการเปิดเผยข้อมูลนั้นง่ายเกินไป

ชุมชนด้านมาตรฐานกำลังเคลื่อนออกจากโมเดลอย่างง่ายนี้แล้ว งานด้าน Verifiable Credentials ของ W3C อธิบายระบบนิเวศที่เกี่ยวข้องกับผู้ออกใบรับรอง ผู้ถือ และผู้ตรวจสอบ โดยใช้นายจ้างและเว็บไซต์เป็นตัวอย่างของผู้ตรวจสอบ งาน mDL (Mobile Driving Licence) ของสหภาพยุโรปได้กำหนดให้การตรวจสอบริมถนนและการเช่ารถเป็นสถานการณ์การตรวจสอบที่แยกจากกัน รวมถึงการแชร์ข้อมูลล่วงหน้าทางไกลสำหรับการเช่า และการตรวจสอบด้วยตนเองสำหรับตำรวจ สถาปัตยกรรมนี้ได้รับการออกแบบมาสำหรับผู้ตรวจสอบหลายประเภทอยู่แล้ว ความผิดพลาดจะเกิดขึ้นหากออกแบบประสบการณ์ผู้ใช้ราวกับว่ามีผู้ตรวจสอบเพียงประเภทเดียว

เหตุใดบัตรใบอนุญาตแบบกายภาพจึงทำให้เราคิดผิด

ใบอนุญาตขับขี่แบบกายภาพได้ฝึกให้เราคุ้นชินกับแนวทางการแสดงข้อมูลทั้งหมด คุณส่งบัตรให้ อีกฝ่ายเห็นสิ่งที่อยู่บนบัตร นั่นคือการโต้ตอบทั้งหมด

แนวทางดังกล่าวเป็นที่ยอมรับในโลกของกระดาษเพราะไม่มีทางเลือกอื่น แต่ในโลกดิจิทัลนั้นไม่อาจยอมรับได้

W3C VC Data Model 2.0 ระบุตรงๆ ว่า ใบอนุญาตขับขี่อาจมีหมายเลขประจำตัว ส่วนสูง น้ำหนัก วันเกิด และที่อยู่บ้าน แต่ข้อมูลเหล่านี้ยังคงมากเกินความจำเป็นสำหรับธุรกรรมหนึ่งๆ ประเด็นสำคัญจากมาตรฐานปัจจุบัน:

• แนวปฏิบัติที่ดีที่สุดของ W3C: รองรับการเปิดเผยข้อมูลเฉพาะส่วน และขอเฉพาะสิ่งที่จำเป็นอย่างเคร่งครัด
• แนวทางการคุ้มครองข้อมูลของสหภาพยุโรป: การประมวลผลต้องจำกัดเฉพาะวัตถุประสงค์ที่ระบุ และข้อมูลที่ประมวลผลต้องจำเป็นและสมส่วน
• หลักการแรกของ IDP ในอนาคต: ข้อมูลรับรองเดียวกันไม่ได้หมายความว่ามีสิทธิ์ตรวจสอบเท่าเทียมกัน

โมเดลที่เหมาะสมคือการเปิดเผยข้อมูลตามนโยบาย

หากต้องการสถาปัตยกรรมที่จริงจัง โมเดลที่เหมาะสมนั้นใกล้เคียงกับการควบคุมการเข้าถึงตามแอตทริบิวต์มากกว่าการนำเสนอบัตรดิจิทัล

NIST SP 800-205 กำหนดการตัดสินใจควบคุมการเข้าถึงว่าเป็นการประเมินแอตทริบิวต์ที่เกี่ยวข้องกับเรื่อง วัตถุ การดำเนินการที่ร้องขอ และสภาพแวดล้อม เทียบกับนโยบาย นั่นคือโครงสร้างที่เหมาะสมสำหรับ IDP ในอนาคต:

• เรื่อง (Subject): ผู้ขับขี่
• วัตถุ (Object): ฟิลด์ข้อมูลที่ร้องขอ
• การดำเนินการ (Action): ไม่ใช่แค่ “ดูใบอนุญาต” แบบนามธรรม แต่เป็นอะไรที่เฉพาะเจาะจง เช่น “ตรวจสอบสิทธิ์ขับขี่รถประเภท B ริมถนน” หรือ “ตรวจสอบสิทธิ์เช่าสำหรับการจอง”
• สภาพแวดล้อม (Environment): ริมถนน เคาน์เตอร์เช่า การตรวจสอบล่วงหน้าทางไกล การรับสมัครพนักงานขับรถ และการพิจารณาสินไหมหลังเกิดเหตุ ล้วนเป็นสภาพแวดล้อมที่แตกต่างกันและควรนำไปสู่การตัดสินใจที่แตกต่างกัน

NIST ยังระบุด้วยว่าระบบแอตทริบิวต์ต้องการความละเอียด การกำกับดูแล และกลไกสำหรับการลด การจัดกลุ่ม และการลดข้อมูลให้น้อยที่สุด

ดังนั้น IDP ในอนาคตไม่ควรถามว่า: ผู้ตรวจสอบนี้อ่านใบอนุญาตได้หรือไม่? แต่ควรถามว่า: ข้อมูลใดที่ผู้ตรวจสอบนี้จะได้รับ สำหรับการใช้งานประสงค์ใด ในสภาพแวดล้อมนี้ และภายใต้กฎการเก็บรักษาข้อมูลแบบใด?

ผู้ตรวจสอบควรระบุตัวตนก่อนร้องขอข้อมูลใดๆ

IDP ในอนาคตไม่ควรเริ่มต้นด้วยกระเป๋าเงินดิจิทัลที่แสดงข้อมูล แต่ควรเริ่มด้วยผู้ตรวจสอบที่พิสูจน์ตัวตนของตนก่อน

สถาปัตยกรรม EUDI ระบุชัดเจนในเรื่องนี้ คู่สัญญา (Relying Parties) ต้อง:

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

จากนั้นผู้ใช้จะเห็นได้ว่าใครกำลังถาม ถามอะไร และคำขอนั้นอยู่ในขอบเขตที่ลงทะเบียนไว้หรือไม่

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

• ชื่อทางการค้า
• URI สำหรับการสนับสนุน
• การใช้งานที่ตั้งใจ
• สิทธิ์ที่มี
• URI ทะเบียน
• ข้อมูลหน่วยงานกำกับดูแล

หลักการที่สองของ IDP ในอนาคต: ไม่มีการระบุตัวตนของผู้ตรวจสอบ ไม่มีการเปิดเผยข้อมูล

เหตุใดหน้าจอขอความยินยอมจึงไม่เพียงพอ

มีข้อผิดพลาดอีกประการหนึ่ง คือการมองว่าการอนุมัติของผู้ใช้เป็นสิ่งเดียวกับความถูกต้องตามกฎหมาย

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

อินเทอร์เฟซกระเป๋าเงินดิจิทัลที่ดีสามารถช่วยได้ แต่ไม่สามารถแก้ปัญหาการขอข้อมูลเกินขอบเขตของผู้ตรวจสอบได้ด้วยตัวเอง กฎต้องมีอยู่ก่อนอินเทอร์เฟซ

ดังนั้น IDP ในอนาคตจำเป็นต้องมีทั้งสองอย่าง:

• การยืนยันตัวตนผู้ตรวจสอบด้วยการเข้ารหัส เพื่อยืนยันว่าใครกำลังถาม
• ข้อจำกัดตามนโยบาย ว่าหมวดหมู่ผู้ตรวจสอบนั้นสามารถขอข้อมูลใดได้บ้าง

หากไม่มีทั้งสองอย่าง “ทางเลือกของผู้ใช้” จะกลายเป็นวิธีโอนความล้มเหลวด้านนโยบายไปยังบุคคล

1. ตำรวจ: ตรวจสอบสิทธิ์การขับขี่ ไม่ใช่ตัวตนทั้งหมด

สถานการณ์การตรวจสอบริมถนนของตำรวจเป็นสถานการณ์ที่มีความเฉพาะเจาะจงมากที่สุด

คู่มือ mDL ของสหภาพยุโรประบุตรงๆ ว่า ตำรวจหรือเจ้าหน้าที่อื่นๆ ตรวจสอบใบอนุญาตเมื่อจำเป็น รวมถึงความถูกต้องของใบอนุญาตและสิทธิ์ใช้ยานพาหนะ ในเส้นทางของผู้ใช้ เจ้าหน้าที่ตรวจสอบใบอนุญาตผ่านกระบวนการที่ใช้ QR โค้ด บลูทูธ Wi-Fi Aware หรือ NFC นั่นคืองานตรวจสอบที่มีความเฉพาะเจาะจง:

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

อนุญาตโดยค่าเริ่มต้น:

• ชื่อ
• รูปถ่าย
• สถานะใบอนุญาต
• วันออกและวันหมดอายุ
• ประเภทยานพาหนะที่ได้รับอนุญาต
• ข้อจำกัดที่เกี่ยวข้องกับการขับขี่
• ผู้ออกและเขตอำนาจศาล
• ผลการตรวจสอบความใหม่/สถานะ

ไม่อนุญาตโดยค่าเริ่มต้น:

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

แนวทางการปฏิบัติของ AAMVA เสริมความสำคัญของรูปถ่าย: หากมีการขอรูปถ่ายและเปิดเผยข้อมูลอื่นๆ ด้วย ควรแชร์รูปถ่ายเพื่อให้ผู้ตรวจสอบสามารถเชื่อมโยงข้อมูลกับบุคคลที่นำเสนอได้ แนวทางเดียวกันยังระบุว่าผู้มีส่วนได้ส่วนเสียต้องไม่ติดตามผู้ถือ mDL หรือการใช้งาน mDL ยกเว้นที่กฎหมายกำหนด

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

2. เคาน์เตอร์เช่ารถ: คุณสมบัติ การยืนยันตัวตน และไม่มีข้อมูลที่ไม่จำเป็น

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

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

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

การตรวจสอบล่วงหน้าทางไกลควรรวมถึง:

• การเชื่อมโยงตัวตน
• รูปถ่ายหรือองค์ประกอบที่ผูกตัวตนเทียบเท่า
• ประเภทยานพาหนะที่เกี่ยวข้อง
• วันออกและวันหมดอายุ
• ความถูกต้องในปัจจุบัน
• อาจมีเกณฑ์อายุหรือช่วงอายุ

การรับรถควรยืนยัน:

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

ไม่จำเป็นโดยค่าเริ่มต้น:

• ที่อยู่บ้านฉบับเต็มเมื่อโปรไฟล์การจองมีข้อมูลติดต่ออยู่แล้ว
• วันเกิดฉบับเต็มเมื่อการยืนยันอายุแบบเกินกว่าหรือช่วงอายุเพียงพอ
• แอตทริบิวต์ตัวตนที่ไม่เกี่ยวข้อง
• การนำเสนอข้อมูลรับรองฉบับเต็มซ้ำหากมีการรับรองการจองอยู่แล้ว

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

3. นายจ้าง: ประเภทผู้ตรวจสอบ ไม่ใช่การเปิดเผยตัวตนทั้งหมด

ภาพรวมของ W3C ใช้ระบบดิจิทัลของนายจ้างที่ตรวจสอบวุฒิการศึกษามหาวิทยาลัยเป็นตัวอย่างผู้ตรวจสอบ ซึ่งเตือนเราว่าการตรวจสอบโดยนายจ้างเป็นรูปแบบที่ได้รับการยอมรับแล้วในระบบนิเวศของข้อมูลรับรอง

นายจ้างหรือผู้ดำเนินการยานพาหนะขององค์กรอาจมีความต้องการที่ถูกต้องตามกฎหมายในการทราบ:

• ลูกจ้างมีสิทธิ์ขับขี่ยานพาหนะประเภทใดในปัจจุบัน
• มีข้อจำกัดสำคัญหรือไม่
• สิทธิ์ยังคงมีผลบังคับใช้หรือไม่

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

NIST เตือนว่าการส่งตัวระบุที่ใช้ซ้ำได้บ่อยครั้งและการทำให้ผู้ใช้คุ้นชินกับการนำเสนอข้อมูลรับรองที่มีตัวตนซ้ำๆ เป็นสิ่งที่ไม่พึงปรารถนา และระบุว่าการยืนยันตัวตนในชีวิตประจำวันควรอาศัยเทคโนโลยีที่ออกแบบมาเพื่อการยืนยันตัวตนโดยเฉพาะ เช่น passkeys NIST ชอบการยืนยันตัวตนบนอุปกรณ์ในพื้นที่มากกว่าการจับคู่ไบโอเมตริกซ์บนเซิร์ฟเวอร์เพราะรักษาความเป็นส่วนตัวได้ดีกว่า

IDP ในอนาคตไม่ควรกลายเป็นบัตรผ่านเข้าที่ทำงาน

สำหรับการใช้งานของนายจ้างและยานพาหนะขององค์กร รูปแบบที่เหมาะสมมักจะเป็น:

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

การปฏิบัติตามข้อกำหนดของยานพาหนะขององค์กรเป็นหมวดหมู่คู่สัญญาที่แยกจากกัน มีการใช้งานที่ตั้งใจแยกต่างหาก และมีโปรไฟล์การเปิดเผยข้อมูลแยกต่างหาก

4. บริษัทประกัน: การเรียกร้องสินไหมไม่ใช่การอนุญาตให้เข้าถึงข้อมูลอย่างต่อเนื่อง

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

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

IDP ในอนาคตควรมองบริษัทประกันเป็นหมวดหมู่ผู้ตรวจสอบที่แยกจากกันพร้อมการใช้งานที่ตั้งใจแยกต่างหาก:

• การรับประกันภัย
• การตรวจสอบความเสี่ยงการเช่า
• การจัดการการเรียกร้องสินไหมหลังเกิดเหตุ
• การตรวจสอบการทุจริต

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

ตัวอย่างที่ถูกต้องตามกฎหมายและเฉพาะเหตุการณ์:

• หลักฐานว่าใบอนุญาตมีผลบังคับใช้ในขณะที่เกี่ยวข้อง
• หลักฐานสิทธิ์ยานพาหนะที่เกี่ยวข้อง
• หลักฐานการเชื่อมโยงตัวตนเมื่อจำเป็นสำหรับการเรียกร้อง
• การเปิดเผยข้อมูลเฉพาะการเรียกร้อง

ไม่อนุญาตโดยค่าเริ่มต้น:

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

ข้อมูลรับรองการขับขี่ไม่ใช่การสมัครรับการติดตาม และไม่ควรกลายเป็นเช่นนั้นอย่างเงียบๆ

เหตุใดตัวกลางจะต้องมองเห็นได้

ตลาดจริงมีตัวกลาง แพลตฟอร์มเช่า ผู้จำหน่ายยานพาหนะขององค์กร ระบบ HR ของนายจ้าง และผู้ประมวลผลการเรียกร้องสินไหมมักดำเนินการผ่านบุคคลที่สาม

สถาปัตยกรรม EUDI จัดการกับสิ่งนี้โดย:

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

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

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

การเก็บรักษาข้อมูลเป็นส่วนหนึ่งของการควบคุมการเข้าถึง

การอภิปรายส่วนใหญ่เกี่ยวกับการเปิดเผยข้อมูลเฉพาะส่วนจบลงเร็วเกินไป พวกเขาเน้นที่สิ่งที่เปิดเผย แต่ไม่ได้เน้นเพียงพอว่ามันยังคงอยู่นานแค่ไหนหลังจากนั้น

แนวทางปัจจุบันกำลังบรรจบกัน:

• AAMVA: กระเป๋าเงินดิจิทัลต้องแจ้งผู้ถืออย่างชัดเจนว่ามีการขอข้อมูลใดและผู้ตรวจสอบตั้งใจจะเก็บรักษาหรือไม่ ผู้มีส่วนได้ส่วนเสียต้องไม่ติดตามผู้ถือหรือการใช้งาน mDL ยกเว้นที่กฎหมายกำหนด
• W3C: ซอฟต์แวร์ผู้ถือควรให้บันทึกข้อมูลที่แชร์กับผู้ตรวจสอบ เพื่อให้สามารถระบุคำขอที่มากเกินไปได้
• EUDI: ผู้ใช้ควรสามารถเข้าถึงบันทึกธุรกรรม รายงานคำขอที่น่าสงสัย และขอลบข้อมูลได้

ระดับการเก็บรักษาควรเป็นส่วนหนึ่งของนโยบายการเปิดเผยข้อมูลเอง:

• ตำรวจริมถนน: ไม่มีการเก็บรักษาโดยค่าเริ่มต้นนอกจากบันทึกปฏิบัติการที่ถูกกฎหมาย
• การตรวจสอบล่วงหน้าการเช่า: บันทึกธุรกรรมที่ผูกกับการจอง ไม่ใช่สำเนาตัวตนที่ใช้ซ้ำได้
• การปฏิบัติตามข้อกำหนดยานพาหนะของนายจ้าง: บันทึกการปฏิบัติตามหรือผลการรับรอง ไม่ใช่ข้อมูลรับรองดิบ
• การเรียกร้องสินไหมประกัน: บันทึกการเรียกร้องที่จำกัดเฉพาะการเรียกร้องนั้น ไม่ใช่การเข้าถึงถาวร

IDP ในอนาคตที่ไม่สนใจการเก็บรักษาข้อมูลเป็นเพียงการรักษาความเป็นส่วนตัวบางส่วนเท่านั้น

สิ่งที่กระเป๋าเงินดิจิทัลควรตัดสินใจจริงๆ

หากต้องสรุปบทความทั้งหมดนี้เป็นกฎการปฏิบัติเพียงข้อเดียว คือ:

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

การตัดสินใจนั้นควรขับเคลื่อนโดยอินพุตเหล่านี้อย่างน้อย:

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

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

ข้อโต้แย้งหลัก

IDP ในอนาคตไม่ควรถามว่าสามารถเปิดเผยข้อมูลได้หรือไม่ แต่ควรถาม:

• ใครที่กำลังถาม?
• เพื่อวัตถุประสงค์ใด?
• ภายใต้อำนาจใด?
• ในบริบทใด?
• ด้วยผลที่ตามมาด้านการเก็บรักษาอะไร?

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

นั่นไม่ใช่ความซับซ้อนที่ไม่จำเป็น นั่นคือสิ่งที่ข้อมูลรับรองการขับขี่สมัยใหม่มีหน้าตาอย่างไรเมื่อหยุดมองผู้ตรวจสอบทุกรายว่าเป็นผู้ตรวจสอบรายเดียวกัน