ຕຳຫຼວດ, ໂຕ໊ະເຊົ່າລົດ, ນາຍຈ້າງ, ບໍລິສັດປະກັນໄພ: ເປັນຫຍັງພວກເຂົາຈຶ່ງຕ້ອງບໍ່ເຫັນຂໍ້ມູນດຽວກັນ

ຄວາມຜິດພາດດ້ານການອອກແບບທີ່ໃຫຍ່ທີ່ສຸດໃນໃບອະນຸຍາດຂັບຂີ່ສາກົນ (IDP) ໃນອະນາຄົດຄືການປະຕິບັດຕໍ່ຜູ້ຢືນຢັນທຸກຄົນຄືກັນ. ເຈົ້າໜ້າທີ່ຕຳຫຼວດ, ໂຕ໊ະເຊົ່າລົດ, ນາຍຈ້າງ, ແລະ ບໍລິສັດປະກັນໄພ ບໍ່ໄດ້ຖາມຄຳຖາມດຽວກັນ — ດັ່ງນັ້ນພວກເຂົາຈຶ່ງບໍ່ຄວນໄດ້ຮັບຄຳຕອບດຽວກັນ.

ຜູ້ຂັບລົດໜຶ່ງຄົນ. ສິດຂັບລົດທີ່ຢູ່ເບື້ອງຫຼັງໜຶ່ງດຽວ. ກະເປົ໋າຜູ້ໃຊ້ (Wallet) ໜຶ່ງດຽວ. ແຕ່ຜູ້ຢືນຢັນທີ່ແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຄືສີ່ຝ່າຍ:

• ເຈົ້າໜ້າທີ່ຕຳຫຼວດລິມຖະໜົນ
• ໂຕ໊ະເຊົ່າລົດໃນເວລາຮັບລົດ
• ນາຍຈ້າງທີ່ກວດສອບສິດທິ໌ການໃຊ້ລົດໃນກອງ
• ບໍລິສັດປະກັນໄພທີ່ກວດສອບການຮ້ອງຮຽນ

ຖ້າ IDP ໃນອະນາຄົດສະແດງຂໍ້ມູນດຽວກັນແກ່ທັງສີ່ຝ່າຍ, ລະບົບດັ່ງກ່າວໄດ້ລົ້ມເຫຼວແລ້ວ. ບໍ່ແມ່ນຍ້ອນໃບຢັ້ງຢືນ (Credential) ບໍ່ປອດໄພ, ແຕ່ຍ້ອນຮູບແບບການເປີດເຜີຍຂໍ້ມູນງ່າຍເກີນໄປ.

ຊຸມຊົນດ້ານມາດຕະຖານກຳລັງຍ້າຍຫ່າງຈາກຮູບແບບທີ່ງ່າຍດາຍນັ້ນຢູ່ແລ້ວ. ວຽກງານ Verifiable Credentials ຂອງ W3C ອະທິບາຍລະບົບນິເວດຮອບດ້ານຜູ້ອອກໃບຢັ້ງຢືນ, ຜູ້ຖືໃບຢັ້ງຢືນ, ແລະ ຜູ້ຢືນຢັນ, ໂດຍໃຊ້ນາຍຈ້າງ ແລະ ເວັບໄຊເປັນຕົວຢ່າງຜູ້ຢືນຢັນ. ວຽກງານໃບຂັບຂີ່ດິຈິຕອນຂອງ ສະຫະພາບເອີຣົບ (EU) ໄດ້ປະຕິບັດຕໍ່ການກວດສອບລິມຖະໜົນ ແລະ ການເຊົ່າລົດໃນຖານະສະຖານະການຢືນຢັນທີ່ແຕກຕ່າງກັນ, ລວມທັງການແບ່ງປັນຂໍ້ມູນລ່ວງໜ້າທາງໄກສຳລັບການເຊົ່າລົດ ແລະ ການກວດສອບດ້ວຍຕົນເອງສຳລັບຕຳຫຼວດ. ສະຖາປັດຕະຍະກຳໄດ້ຖືກອອກແບບໄວ້ສຳລັບຜູ້ຢືນຢັນຫຼາຍປະເພດຢູ່ແລ້ວ. ຄວາມຜິດພາດຄືການອອກແບບປະສົບການຜູ້ໃຊ້ຄືກັບວ່າມີຜູ້ຢືນຢັນພຽງປະເພດດຽວເທົ່ານັ້ນ.

ເປັນຫຍັງບັດໃບຂັບຂີ່ຮູບຊົງກາຍຈຶ່ງຝຶກໃຫ້ເຮົາຄິດຜິດ

ໃບຂັບຂີ່ຮູບຊົງກາຍໄດ້ຝຶກໃຫ້ເຮົາຄຸ້ນເຄີຍກັບວິທີການສະແດງທຸກຢ່າງ. ທ່ານຍື່ນບັດ. ອີກຝ່າຍເຫັນສິ່ງທີ່ຢູ່ໃນບັດ. ນັ້ນຄືການໂຕ້ຕອບທັງໝົດ.

ວິທີການດັ່ງກ່າວຍອມຮັບໄດ້ໃນໂລກກາງເຈ້ຍ ເພາະບໍ່ມີທາງເລືອກອື່ນ. ແຕ່ມັນກາຍເປັນສິ່ງທີ່ຍອມຮັບບໍ່ໄດ້ໃນໂລກດິຈິຕອນ.

W3C VC Data Model 2.0 ລະບຸໂດຍກົງວ່າ: ໃບຂັບຂີ່ອາດຈະມີໝາຍເລກ ID, ສ່ວນສູງ, ນ້ຳໜັກ, ວັນເດືອນປີເກີດ, ແລະ ທີ່ຢູ່ເຮືອນ — ແຕ່ສິ່ງເຫຼົ່ານີ້ຍັງອາດຫຼາຍກວ່າທີ່ຈຳເປັນສຳລັບການເຮັດທຸລະກຳໃດໜຶ່ງ. ຈຸດສຳຄັນຂອງມາດຕະຖານໃນປັດຈຸບັນ:

• ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ W3C: ຮອງຮັບການເປີດເຜີຍຂໍ້ມູນແບບຄັດເລືອກ, ແລະ ຂໍສະເພາະສິ່ງທີ່ຈຳເປັນຢ່າງເຂັ້ມງວດ
• ແນວທາງການຄຸ້ມຄອງຂໍ້ມູນສ່ວນຕົວຂອງ ສະຫະພາບເອີຣົບ (EU): ການປຸງແຕ່ງຕ້ອງຈຳກັດຕາມຈຸດປະສົງທີ່ລະບຸ, ແລະ ຂໍ້ມູນທີ່ປຸງແຕ່ງຕ້ອງຈຳເປັນ ແລະ ສົມຄວນ
• ຫຼັກການທຳອິດຂອງ IDP ໃນອະນາຄົດ: ໃບຢັ້ງຢືນດຽວກັນບໍ່ໄດ້ໝາຍຄວາມວ່າມີສິດກວດສອບດຽວກັນ

ຮູບແບບທີ່ຖືກຕ້ອງຄືການເປີດເຜີຍໂດຍອີງໃສ່ນະໂຍບາຍ

ຖ້າທ່ານຕ້ອງການສະຖາປັດຕະຍະກຳທີ່ຈິງຈັງ, ຮູບແບບທີ່ຖືກຕ້ອງແມ່ນໃກ້ຄຽງກັບການຄວບຄຸມການເຂົ້າໃຊ້ໂດຍອີງໃສ່ຄຸນລັກສະນະ (Attribute-Based Access Control) ຫຼາຍກວ່າການນຳສະເໜີບັດດິຈິຕອນ.

NIST SP 800-205 ກຳນົດການຕັດສິນໃຈຄວບຄຸມການເຂົ້າໃຊ້ວ່າເປັນການປະເມີນຄຸນລັກສະນະທີ່ກ່ຽວຂ້ອງກັບຫົວຂໍ້ (Subject), ວັດຖຸ (Object), ການດຳເນີນການທີ່ຮ້ອງຂໍ, ແລະ ເງື່ອນໄຂສິ່ງແວດລ້ອມ ທຽບກັບນະໂຍບາຍ. ນັ້ນແມ່ນໂຄງສ້າງທີ່ຖືກຕ້ອງສຳລັບ IDP ໃນອະນາຄົດ:

• ຫົວຂໍ້ (Subject): ຜູ້ຂັບລົດ
• ວັດຖຸ (Object): ຊ່ອງຂໍ້ມູນທີ່ຮ້ອງຂໍ
• ການດຳເນີນການ (Action): ບໍ່ແມ່ນ “ເຫັນໃບຂັບຂີ່” ໃນຄວາມໝາຍທົ່ວໄປ, ແຕ່ໝາຍຄວາມສະເພາະເຊັ່ນ “ຢືນຢັນສິດຂັບລົດໝວດ B ລິມຖະໜົນ” ຫຼື “ຢືນຢັນສິດທິ໌ເຊົ່າລົດສຳລັບການຈອງ”
• ສິ່ງແວດລ້ອມ (Environment): ລິມຖະໜົນ, ໂຕ໊ະເຊົ່າລົດ, ການກວດສອບລ່ວງໜ້າທາງໄກ, ການຮັບສະໝັກໃຊ້ລົດກອງ, ແລະ ການກວດສອບໃບຮ້ອງຮຽນຫຼັງໄດ້ຮັບຄວາມເສຍຫາຍ ເປັນສິ່ງແວດລ້ອມທີ່ແຕກຕ່າງກັນ ແລະ ຄວນນຳໄປສູ່ການຕັດສິນໃຈທີ່ແຕກຕ່າງກັນ

NIST ຍັງຊີ້ໃຫ້ເຫັນວ່າລະບົບຄຸນລັກສະນະຕ້ອງການຄວາມລະອຽດ, ການຄຸ້ມຄອງ, ແລະ ກົນໄກສຳລັບການຫຼຸດລົງ, ການຈັດກຸ່ມ, ແລະ ການຫຼຸດຜ່ອນຄຸນລັກສະນະ.

ດັ່ງນັ້ນ IDP ໃນອະນາຄົດບໍ່ຄວນຖາມວ່າ: ຜູ້ຢືນຢັນນີ້ສາມາດອ່ານໃບຂັບຂີ່ໄດ້ບໍ? ມັນຄວນຖາມວ່າ: ຜູ້ຢືນຢັນນີ້ອາດໄດ້ຮັບຂໍ້ຮຽກຮ້ອງໃດ, ສຳລັບຈຸດປະສົງທີ່ຕັ້ງໃຈໃດ, ໃນສິ່ງແວດລ້ອມນີ້, ດ້ວຍກົດລະບຽບການເກັບຮັກສາໃດ?

ຜູ້ຢືນຢັນຄວນພິສູດຕົວຕົນກ່ອນທີ່ຈະຮ້ອງຂໍສິ່ງໃດ

IDP ໃນອະນາຄົດຄວນບໍ່ເລີ່ມຕົ້ນດ້ວຍກະເປົ໋າຜູ້ໃຊ້ (Wallet) ສະແດງຂໍ້ມູນ. ມັນຄວນເລີ່ມຕົ້ນດ້ວຍຜູ້ຢືນຢັນພິສູດວ່າຕົນເອງເປັນໃຜ.

ສະຖາປັດຕະຍະກຳ EUDI ຊັດເຈນໃນເລື່ອງນີ້. ພາກສ່ວນທີ່ອ່ອນອາໄສ (Relying Parties) ຕ້ອງ:

• ລົງທະບຽນຄຸນລັກສະນະທີ່ຕົນຕັ້ງໃຈຮ້ອງຂໍ ແລະ ເພື່ອຈຸດປະສົງໃດ
• ໄດ້ຮັບໃບຢັ້ງຢືນການເຂົ້າໃຊ້
• ພິສູດຕົວຕົນກັບກະເປົ໋າຜູ້ໃຊ້ (Wallet) ກ່ອນການເປີດເຜີຍຂໍ້ມູນໃດໆ
• ຖືກກວດສອບທຽບກັບຂອບເຂດທີ່ລົງທະບຽນ, ໃນຈຸດທີ່ຂໍ້ມູນການລົງທະບຽນມີໃຫ້

ຜູ້ໃຊ້ສາມາດເຫັນໄດ້ວ່າໃຜກຳລັງຖາມ, ສິ່ງທີ່ຖືກຮ້ອງຂໍ, ແລະ ວ່າການຮ້ອງຂໍຢູ່ໃນຂອບເຂດທີ່ລົງທະບຽນໄວ້ຫຼືບໍ່.

ວຽກງານໃບຢັ້ງຢືນ Wallet-Relying-Party ໃນປັດຈຸບັນຂອງ ETSI ເຮັດໃຫ້ສິ່ງນີ້ຊັດເຈນຂຶ້ນ. ໃບຢັ້ງຢືນການລົງທະບຽນ Wallet-Relying-Party ສາມາດອະທິບາຍຈຸດປະສົງການໃຊ້ງານທີ່ຕັ້ງໃຈ ແລະ ຄຸນລັກສະນະທີ່ລົງທະບຽນໄວ້ສຳລັບການຮ້ອງຂໍ. ໃບຢັ້ງຢືນການເຂົ້າໃຊ້ທີ່ກ່ຽວຂ້ອງມີຢູ່ເພື່ອໃຫ້ການຮ້ອງຂໍມາຈາກພາກສ່ວນທີ່ຖືກຕ້ອງ ແລະ ໄດ້ຮັບອະນຸຍາດ. ETSI ຍັງລວມເອົາຂໍ້ມູນ Metadata ຂອງ Relying Party ເຊັ່ນ:

• ຊື່ທາງການຄ້າ
• URI ສະໜັບສະໜູນ
• ຈຸດປະສົງການໃຊ້ງານ
• ສິດທິ໌
• URI ທະບຽນ
• ຂໍ້ມູນໜ່ວຍງານຄຸມຄອງ

ຫຼັກການທີສອງຂອງ IDP ໃນອະນາຄົດ: ບໍ່ມີການພິສູດຕົວຕົນຜູ້ຢືນຢັນ, ບໍ່ມີການເປີດເຜີຍຂໍ້ມູນ.

ເປັນຫຍັງໜ້າຈໍຍິນຍອມຈຶ່ງບໍ່ພຽງພໍ

ມີຄວາມຜິດພາດອີກຢ່າງໜຶ່ງ: ການປະຕິບັດຕໍ່ການອະນຸມັດຂອງຜູ້ໃຊ້ຄືສິ່ງດຽວກັນກັບຄວາມຖືກຕ້ອງທາງກົດໝາຍ.

ສະຖາປັດຕະຍະກຳ EUDI ລະບຸຊັດເຈນວ່າການອະນຸມັດຂອງຜູ້ໃຊ້ໃນການສະແດງຄຸນລັກສະນະຕ້ອງບໍ່ຖືເປັນເຫດຜົນທາງກົດໝາຍສຳລັບການປຸງແຕ່ງຂໍ້ມູນສ່ວນຕົວຂອງ Relying Party. Relying Party ຍັງຕ້ອງມີຖານທາງກົດໝາຍຂອງຕົນເອງ. EUDI ຍັງກຳນົດໃຫ້ຕ້ອງໄດ້ຮັບການອະນຸມັດຈາກຜູ້ໃຊ້ໃນທຸກກໍລະນີການໃຊ້ງານ, ລວມທັງກໍລະນີທີ່ Relying Party ອາດເປັນສ່ວນໜຶ່ງຂອງໜ່ວຍງານບັງຄັບໃຊ້ກົດໝາຍຫຼືໜ່ວຍງານລັດຖະບານ.

ໜ້າຈໍ Wallet ທີ່ດີສາມາດຊ່ວຍໄດ້, ແຕ່ບໍ່ສາມາດແກ້ໄຂການລ່ວງເກີນຂອງຜູ້ຢືນຢັນດ້ວຍຕົນເອງ. ກົດລະບຽບຕ້ອງມີກ່ອນໜ້າຈໍ.

IDP ໃນອະນາຄົດດັ່ງນັ້ນຕ້ອງການທັງສອງ:

• ການພິສູດຕົວຕົນຜູ້ຢືນຢັນດ້ວຍລະຫັດເຂົ້າລະຫັດ (Cryptographic Verifier Authentication) ເພື່ອຢືນຢັນວ່າໃຜກຳລັງຖາມ
• ຂໍ້ຈຳກັດຕາມນະໂຍບາຍ (Policy Constraints) ວ່າໝວດໝູ່ຜູ້ຢືນຢັນນັ້ນສາມາດຮ້ອງຂໍສິ່ງໃດໄດ້

ຖ້າຂາດທັງສອງ, “ທາງເລືອກຂອງຜູ້ໃຊ້” ກາຍເປັນວິທີໂຍນຄວາມລົ້ມເຫຼວດ້ານນະໂຍບາຍໃຫ້ແກ່ບຸກຄົນ.

1. ຕຳຫຼວດ: ຢືນຢັນສິດຂັບລົດ, ບໍ່ແມ່ນຕົວຕົນທັງໝົດ

ສະຖານະການຕຳຫຼວດລິມຖະໜົນເປັນສະຖານະການທີ່ສຸ້ມສ່ຽງທີ່ສຸດ.

ຄູ່ມື mDL ຂອງ ສະຫະພາບເອີຣົບ (EU) ອະທິບາຍໂດຍກົງ: ຕຳຫຼວດຫຼືເຈົ້າໜ້າທີ່ອື່ນໆກວດສອບໃບຂັບຂີ່ເມື່ອຈຳເປັນ, ລວມທັງຄວາມຖືກຕ້ອງຂອງໃບຂັບຂີ່ ແລະ ສິດທິ໌ໃຊ້ລົດ. ໃນເສັ້ນທາງຜ່ານຂອງຜູ້ໃຊ້ (User Journey), ເຈົ້າໜ້າທີ່ກວດສອບໃບຂັບຂີ່ຜ່ານຂັ້ນຕອນ QR, Bluetooth, Wi-Fi Aware, ຫຼື NFC. ນັ້ນເປັນວຽກງານການຢືນຢັນທີ່ຊັດເຈນ:

• ຄົນນີ້ເປັນຜູ້ຖືໃບຢັ້ງຢືນບໍ?
• ໃບຢັ້ງຢືນຍັງຖືກຕ້ອງຢູ່ບໍ?
• ສິດທິ໌ ແລະ ຂໍ້ຈຳກັດໃດທີ່ໃຊ້ກັບລົດ?

ອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ:

• ຊື່
• ຮູບໃບໜ້າ
• ສະຖານະໃບຂັບຂີ່
• ວັນທີອອກ ແລະ ໝົດອາຍຸ
• ໝວດໝູ່
• ຂໍ້ຈຳກັດທີ່ກ່ຽວຂ້ອງກັບການຂັບລົດ
• ຜູ້ອອກ ແລະ ເຂດອຳນາດສານ
• ຜົນການກວດຄວາມຖ່ຽງໃໝ່/ສະຖານະ

ບໍ່ອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ:

• ທີ່ຢູ່ເຮືອນ
• ໝາຍເລກລະຫັດພາຍໃນທີ່ບໍ່ຈຳເປັນສຳລັບການໃຊ້ລິມຖະໜົນ
• ຄຸນລັກສະນະທີ່ບໍ່ກ່ຽວຂ້ອງຈາກໃບຢັ້ງຢືນອື່ນ
• ບັນທຶກການນຳສະເໜີໃນອະດີດ
• ຂໍ້ມູນ Metadata ທາງການຄ້າ

ແນວທາງການຈັດຕັ້ງປະຕິບັດຂອງ AAMVA ຢືນຢັນໃນຈຸດກ່ຽວກັບຮູບໃບໜ້າ: ຖ້າຮູບໃບໜ້າຖືກຮ້ອງຂໍ ແລະ ອົງປະກອບໃດໜຶ່ງຖືກເປີດເຜີຍ, ຮູບໃບໜ້າຄວນຖືກແບ່ງປັນ ເພື່ອໃຫ້ຜູ້ຢືນຢັນສາມາດເຊື່ອມຂໍ້ມູນກັບຜູ້ນຳສະເໜີ. ແນວທາງດຽວກັນຍັງລະບຸວ່າຜູ້ທີ່ກ່ຽວຂ້ອງຕ້ອງໄດ້ບໍ່ຕິດຕາມຜູ້ຖື mDL ຫຼືການໃຊ້ mDL ຍົກເວັ້ນໃນກໍລະນີທີ່ກົດໝາຍກຳນົດ.

ກໍລະນີຕຳຫຼວດບໍ່ແມ່ນເລື່ອງທີ່ລັດຖະບານໄດ້ຮັບທຸກຢ່າງ. ມັນຄືການທີ່ລັດຖະບານໄດ້ຮັບຂໍ້ມູນສະເພາະດ້ານການຂັບລົດທີ່ຈຳເປັນສຳລັບການບັງຄັບໃຊ້ລິມຖະໜົນ. ນັ້ນເປັນຄວາມແຕກຕ່າງທີ່ສຳຄັນ.

2. ໂຕ໊ະເຊົ່າລົດ: ສິດທິ໌, ການຈັບຄູ່ຕົວຕົນ, ແລະ ບໍ່ມີສິ່ງທີ່ບໍ່ຈຳເປັນ

ກໍລະນີການເຊົ່າລົດມີລາຍລະອຽດຫຼາຍຂຶ້ນ ເພາະມີສອງຊ່ວງເວລາຈິງ: ການກວດສອບລ່ວງໜ້າທາງໄກກ່ອນໄປຮອດ, ແລະ ເວລາຮັບລົດທີ່ຄົນຫຼືຕູ້ Kiosk ມອບກຸນແຈ.

ຄູ່ມື mDL ຂອງ ສະຫະພາບເອີຣົບ (EU) ໄດ້ສ້າງຕົວແບບທັງສອງຢ່າງ. ບໍລິສັດເຊົ່າລົດສາມາດຮ້ອງຂໍ mDL ພ້ອມກັບຫຼັກຖານຕົວຕົນໃນລະຫວ່າງການຈອງ, ກວດສອບໃບຢັ້ງຢືນ, ແລະ ຕໍ່ມາຢືນຢັນລູກຄ້າດ້ວຍຕົນເອງໃນເວລາຮັບລົດກ່ອນຈະໃຫ້ລົດ. ຜູ້ໃຊ້ສາມາດແບ່ງປັນ mDL ຂອງຕົນກັບບໍລິສັດເຊົ່າລົດທັງດ້ວຍຕົນເອງ ຫຼື ລ່ວງໜ້າທາງໄກ.

ໂຕ໊ະເຊົ່າລົດບໍ່ຕ້ອງການສືບສວນເຫດການເປັນຫຼັກ. ມັນຕ້ອງການຕັດສິນໃຈ: ຂ້ອຍສາມາດໃຫ້ລົດນີ້ແກ່ລູກຄ້ານີ້ພາຍໃຕ້ການຈອງ ແລະ ນະໂຍບາຍນີ້ໄດ້ບໍ?

ການກວດສອບລ່ວງໜ້າທາງໄກຄວນລວມ:

• ການເຊື່ອມຕໍ່ຕົວຕົນ
• ຮູບໃບໜ້າຫຼືອົງປະກອບເຊື່ອມຕົວຕົນທີ່ທຽບເທົ່າ
• ໝວດໝູ່ລົດທີ່ກ່ຽວຂ້ອງ
• ວັນທີອອກ ແລະ ໝົດອາຍຸ
• ຄວາມຖືກຕ້ອງໃນປັດຈຸບັນ
• ອາດລວມເຖິງເກນອາຍຸ ຫຼື ກຸ່ມອາຍຸ

ການຮັບລົດຄວນຢືນຢັນ:

• ຜູ້ຖືໃບຢັ້ງຢືນເປັນຄົນດຽວກັນກັບຜູ້ທີ່ຜ່ານການກວດສອບລ່ວງໜ້າ
• ຄວາມຖືກຕ້ອງໃນປັດຈຸບັນ
• ສິດທິ໌ທີ່ກ່ຽວຂ້ອງ

ບໍ່ຈຳເປັນໂດຍຄ່າເລີ່ມຕົ້ນ:

• ທີ່ຢູ່ເຮືອນຄົບຖ້ວນໃນກໍລະນີທີ່ໂປຣໄຟລ໌ການຈອງມີລາຍລະອຽດການຕິດຕໍ່ຢູ່ແລ້ວ
• ວັນເດືອນປີເກີດຄົບຖ້ວນໃນກໍລະນີທີ່ການຢືນຢັນ “ອາຍຸຫຼາຍກວ່າ” ຫຼື ກຸ່ມອາຍຸພຽງພໍ
• ຄຸນລັກສະນະຕົວຕົນທີ່ບໍ່ກ່ຽວຂ້ອງ
• ການນຳສະເໜີໃບຢັ້ງຢືນຄົບຊຸດຊ້ຳຄັ້ງທີສອງ ຖ້າໃບຢັ້ງຢືນການຈອງມີຢູ່ແລ້ວ

ສະຖາປັດຕະຍະກຳ mDL ປັດຈຸບັນຂອງ NIST ສະແດງໃຫ້ Relying Party ໃຊ້ DCQL ເພື່ອຮ້ອງຂໍສະເພາະຄຸນລັກສະນະທີ່ຕ້ອງການ, ແລະ ລະບຸຊັດເຈນວ່ານີ້ສະໜັບສະໜູນການຫຼຸດຜ່ອນຂໍ້ມູນ ແລະ ການຍິນຍອມຂອງຜູ້ຖືໃບຢັ້ງຢືນ ໂດຍຈັດໂຄງສ້າງການຮ້ອງຂໍແທນທີ່ຈະປະຕິບັດຕໍ່ໃບຢັ້ງຢືນເປັນໜ່ວຍດຽວ. AAMVA ເພີ່ມເຕີມວ່າແອັບພລິເຄຊັນຄວນສະແດງຢ່າງຊັດເຈນວ່າຂໍ້ມູນໃດຖືກຮ້ອງຂໍ ແລະ ວ່າຜູ້ຢືນຢັນຕັ້ງໃຈເກັບຮັກສາຂໍ້ມູນຫຼືບໍ່.

3. ນາຍຈ້າງ: ໝວດໝູ່ຜູ້ຢືນຢັນ, ບໍ່ແມ່ນຊ່ອງທາງສູ່ຕົວຕົນທັງໝົດ

ພາບລວມຂອງ W3C ໃຊ້ລະບົບດິຈິຕອນຂອງນາຍຈ້າງທີ່ກວດສອບໃບຢັ້ງຢືນມະຫາວິທະຍາໄລເປັນຕົວຢ່າງຜູ້ຢືນຢັນ. ນັ້ນເຕືອນໃຫ້ເຮົາຮູ້ວ່າການຢືນຢັນຈາກນາຍຈ້າງເປັນຮູບແບບທີ່ໄດ້ຮັບການຍອມຮັບຢ່າງແທ້ຈິງໃນລະບົບນິເວດໃບຢັ້ງຢືນ.

ນາຍຈ້າງຫຼືຜູ້ດຳເນີນການກອງລົດອາດຈຳເປັນຕ້ອງຮູ້ຢ່າງຖືກຕ້ອງ:

• ວ່າພະນັກງານມີສິດຂັບລົດໝວດໝູ່ໃດໃນປັດຈຸບັນ
• ວ່າມີຂໍ້ຈຳກັດສຳຄັນໃດຢູ່ຫຼືບໍ່
• ວ່າສິດທິ໌ຍັງຖືກຕ້ອງຢູ່ຫຼືບໍ່

ນັ້ນເປັນຄວາມຕ້ອງການທາງທຸລະກິດທີ່ແທ້ຈິງ. ແຕ່ມັນບໍ່ໄດ້ຮັບຮອງໂດຍອັດຕະໂນມັດໃຫ້ເຂົ້າໃຊ້ໃບຢັ້ງຢືນການຂັບລົດທັງໝົດ, ຂໍ້ມູນຕົວຕົນຄົບຊຸດ, ຫຼື ກະແສການນຳສະເໜີຊ້ຳຕໍ່ເນື່ອງ.

NIST ເຕືອນວ່າການສົ່ງ Identifier ທີ່ໃຊ້ຊ້ຳໄດ້ຄັ້ງແລ້ວຄັ້ງເລົ່າ ແລະ ການກຳນົດໃຫ້ຜູ້ໃຊ້ສະແດງໃບຢັ້ງຢືນທີ່ມີຕົວຕົນຊ້ຳໆ ເປັນສິ່ງທີ່ບໍ່ດີ, ແລະ ກ່າວວ່າການພິສູດຕົວຕົນປະຈຳວັນຄວນໃຊ້ເທັກໂນໂລຊີທີ່ອອກແບບສຳລັບການພິສູດຕົວຕົນ ເຊັ່ນ Passkeys. NIST ມັກໃຊ້ການພິສູດຕົວຕົນໃນອຸປະກອນທ້ອງຖິ່ນຫຼາຍກວ່າການຈັບຄູ່ Biometric ຢູ່ Server ເພາະຮັກສາຄວາມເປັນສ່ວນຕົວໄດ້ດີກວ່າ.

IDP ໃນອະນາຄົດບໍ່ຄວນກາຍເປັນບັດເຂົ້າສະຖານທີ່ເຮັດວຽກ.

ສຳລັບການໃຊ້ງານຂອງນາຍຈ້າງ ແລະ ກອງລົດ, ຮູບແບບທີ່ຖືກຕ້ອງໂດຍທົ່ວໄປຄື:

• ການກວດສອບສິດທິ໌ທີ່ກ່ຽວຂ້ອງກັບວຽກ
• ບາງທີການຢືນຢັນການປະຕິບັດຕາມໄລຍະ
• ບາງທີການຮ້ອງຮຽນວ່າຜູ້ຖືໃບຢັ້ງຢືນຍັງຖືກຕ້ອງສຳລັບໝວດໝູ່ທີ່ລະບຸ
• ແຕ່ບໍ່ແມ່ນການໂອນຂໍ້ມູນໃບຂັບຂີ່ທັງໝົດໂດຍຄ່າເລີ່ມຕົ້ນ ທຸກຄັ້ງທີ່ພະນັກງານ Login ເຂົ້າລະບົບ ຫຼື ເລີ່ມຕົ້ນກະ

ການປະຕິບັດຕາມຂໍ້ກຳນົດກອງລົດເປັນໝວດໝູ່ Relying Party ທີ່ແຍກຕ່າງຫາກ, ດ້ວຍຈຸດປະສົງການໃຊ້ງານທີ່ແຍກຕ່າງຫາກ, ແລະ ໂປຣໄຟລ໌ການເປີດເຜີຍຂໍ້ມູນທີ່ແຍກຕ່າງຫາກ.

4. ບໍລິສັດປະກັນໄພ: ການຮ້ອງຮຽນບໍ່ແມ່ນການອະນຸຍາດໃຫ້ເຫັນຢ່າງຕໍ່ເນື່ອງ

ກໍລະນີການປະກັນໄພຄືຄວາມຈິງທີ່ເກີດຂຶ້ນເລື້ອຍໆ. ໃນ ເອກະສານກໍລະນີການໃຊ້ mDL ຂອງ ສະຫະພາບເອີຣົບ (EU), ບໍລິສັດປະກັນໄພປາກົດໂດຍທາງອ້ອມໃນສະຖານະການການເຊົ່າລົດ: ບໍລິສັດປະກັນໄພກຳນົດໃຫ້ບໍລິສັດເຊົ່າລົດກວດສອບວ່າຜູ້ທີ່ເຊົ່າລົດມີສິດຂັບລົດ. ການປະກັນໄພໄດ້ສ່ົງຜົນກະທົບຕໍ່ຂັ້ນຕອນການຢືນຢັນການຂັບລົດຢູ່ແລ້ວ.

ແຕ່ນັ້ນບໍ່ໄດ້ໝາຍຄວາມວ່າບໍລິສັດປະກັນໄພຄວນໄດ້ຮັບຂໍ້ມູນດຽວກັນກັບຕຳຫຼວດ, ຫຼື ສິດເຂົ້າໃຊ້ໃບຢັ້ງຢືນຢ່າງຖາວອນ.

IDP ໃນອະນາຄົດຄວນປະຕິບັດຕໍ່ບໍລິສັດປະກັນໄພເປັນໝວດໝູ່ຜູ້ຢືນຢັນທີ່ແຍກຕ່າງຫາກ ດ້ວຍຈຸດປະສົງການໃຊ້ງານທີ່ແຍກຕ່າງຫາກ:

• ການພິຈາລະນາຮັບປະກັນ (Underwriting)
• ການຢືນຢັນຄວາມສ່ຽງການເຊົ່າ
• ການຈັດການໃບຮ້ອງຮຽນຫຼັງໄດ້ຮັບຄວາມເສຍຫາຍ
• ການກວດສອບການສໍ້ໂກງ

ເຫຼົ່ານີ້ບໍ່ແມ່ນຈຸດປະສົງດຽວກັນ. ພາຍໃຕ້ຫຼັກການຄຸ້ມຄອງຂໍ້ມູນສ່ວນຕົວຂອງ ສະຫະພາບເອີຣົບ (EU), ຂໍ້ມູນສ່ວນຕົວຕ້ອງຖືກເກັບຮວບຮວມສຳລັບຈຸດປະສົງທີ່ລະບຸ ແລະ ຈຳກັດໃຫ້ຈຳເປັນ ແລະ ສົມຄວນສຳລັບຈຸດປະສົງດັ່ງກ່າວ. ແນວທາງ VC ຂອງ W3C ໄດ້ຂໍ້ສະຫຼຸບດຽວກັນໃນດ້ານເທັກນິກ: ຜູ້ຢືນຢັນຄວນຮ້ອງຂໍສະເພາະສິ່ງທີ່ຈຳເປັນຢ່າງເຂັ້ມງວດ.

ຕົວຢ່າງທີ່ຖືກຕ້ອງ ແລະ ກ່ຽວຂ້ອງກັບເຫດການ:

• ຫຼັກຖານວ່າໃບຂັບຂີ່ຖືກຕ້ອງໃນຊ່ວງເວລາທີ່ກ່ຽວຂ້ອງ
• ຫຼັກຖານສິດທິ໌ໃຊ້ລົດທີ່ກ່ຽວຂ້ອງ
• ຫຼັກຖານການເຊື່ອມຕໍ່ຕົວຕົນໃນກໍລະນີທີ່ຈຳເປັນສຳລັບການຮ້ອງຮຽນ
• ການເປີດເຜີຍຂໍ້ມູນສະເພາະການຮ້ອງຮຽນ

ບໍ່ອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ:

• ການເຂົ້າໃຊ້ໃບຢັ້ງຢືນຫຼັກຢ່າງຕໍ່ເນື່ອງ
• ການຢືນຢັນທົ່ວໄປຊ້ຳໆ ທຸກຄັ້ງທີ່ລູກຄ້າໂຕ້ຕອບກັບບໍລິສັດປະກັນໄພ
• ການໃຊ້ໃບຢັ້ງຢືນການຂັບລົດເປັນໂທເຄັນ Login
• ການເກັບຮວບຮວມຄຸນລັກສະນະທີ່ບໍ່ກ່ຽວຂ້ອງ

ໃບຢັ້ງຢືນການຂັບລົດບໍ່ແມ່ນການສະໝັກສະມາຊິກຕິດຕາມ. ແລະ ມັນບໍ່ຄວນກາຍເປັນແບບນັ້ນຢ່າງງຽບໆ.

ເປັນຫຍັງຜູ້ກາງຈຶ່ງຕ້ອງມີຄວາມໂປ່ງໃສ

ຕະຫຼາດທີ່ແທ້ຈິງມີຜູ້ກາງ. ແພລດຟອມເຊົ່າລົດ, ຜູ້ຂາຍລົດກອງ, ລະບົບ HR ຂອງນາຍຈ້າງ, ແລະ ຜູ້ດຳເນີນການໃບຮ້ອງຮຽນປະກັນໄພ ມັກດຳເນີນການຜ່ານພາກທີສາມ.

ສະຖາປັດຕະຍະກຳ EUDI ຈັດການສິ່ງນີ້ໂດຍ:

• ປະຕິບັດຕໍ່ຜູ້ກາງໃນຖານະ Relying Parties
• ກຳນົດໃຫ້ພວກເຂົາລົງທະບຽນ
• ກຳນົດໃຫ້ຄຸນລັກສະນະທີ່ຮ້ອງຂໍສຳລັບ Relying Party ທີ່ໃຊ້ຜູ້ກາງຕ້ອງໄດ້ລົງທະບຽນ
• ສະແດງທັງຜູ້ກາງ ແລະ Relying Party ສຸດທ້າຍໃຫ້ຜູ້ໃຊ້ເຫັນ
• ຫ້າມຜູ້ກາງເກັບຂໍ້ມູນກ່ຽວກັບເນື້ອໃນຂອງທຸລະກຳ

IDP ໃນອະນາຄົດຄວນບໍ່ອະນຸຍາດໃຫ້ຮູບແບບທີ່ຜູ້ໃຊ້ເຊື່ອວ່າຕົນເຊົ່ຍເປີດເຜີຍຂໍ້ມູນໃຫ້ບໍລິສັດເຊົ່າລົດ, ແຕ່ໃນຄວາມເປັນຈິງ ພວກເຂົາກຳລັງເປີດເຜີຍຂໍ້ມູນໃຫ້ ຕ່ອງໂສ້ຂອງນາຍໜ້າການຢືນຢັນທີ່ຊ່ອນຢູ່, ຜູ້ດຳເນີນການວິເຄາະ, ແລະ ຜູ້ຂາຍການຮ້ອງຮຽນ.

ETSI ຊ່ວຍໄດ້ໃນຈຸດນີ້. ຮູບແບບໃບຢັ້ງຢືນ Wallet-Relying-Party ຂອງ ETSI ລວມ URI ສະໜັບສະໜູນ, ຈຸດປະສົງການໃຊ້ງານ, URI ທະບຽນ, ແລະ ຂໍ້ມູນ Metadata ຂອງໜ່ວຍງານຄຸມຄອງ. ນັ້ນຄືປະເພດຂອງໂຄງສ້າງພື້ນຖານທີ່ອ່ານໄດ້ດ້ວຍເຄື່ອງຈັກ ທີ່ຈຳເປັນໃຫ້ຜູ້ໃຊ້ເຂົ້າໃຈວ່າໃຜຢູ່ອີກດ້ານໜຶ່ງຂອງການຮ້ອງຂໍ ແລະ ຈະໄປທາງໃດເມື່ອຕ້ອງການລົບ ຫຼື ແກ້ໄຂຂໍ້ມູນ.

ການເກັບຮັກສາຂໍ້ມູນເປັນສ່ວນໜຶ່ງຂອງການຄວບຄຸມການເຂົ້າໃຊ້

ການສົນທະນາສ່ວນໃຫຍ່ກ່ຽວກັບການເປີດເຜີຍຂໍ້ມູນແບບຄັດເລືອກຈົບໄວເກີນໄປ. ພວກເຂົາສຸ້ມໃສ່ສິ່ງທີ່ຖືກເປີດເຜີຍ. ພວກເຂົາບໍ່ສຸ້ມໃສ່ໃຫ້ພຽງພໍວ່າຈະຢູ່ດົນປານໃດຫຼັງຈາກນັ້ນ.

ແນວທາງໃນປັດຈຸບັນໄດ້ເຊື່ອມໂຍງກັນຢ່າງຕໍ່ເນື່ອງ:

• AAMVA: Wallet ຕ້ອງບອກຜູ້ຖືໃບຢັ້ງຢືນຢ່າງຊັດເຈນວ່າຂໍ້ມູນໃດຖືກຮ້ອງຂໍ ແລະ ວ່າຜູ້ຢືນຢັນຕັ້ງໃຈເກັບຮັກສາໄວ້ຫຼືບໍ່; ຜູ້ທີ່ກ່ຽວຂ້ອງຕ້ອງໄດ້ບໍ່ຕິດຕາມຜູ້ຖືໃບຢັ້ງຢືນ ຫຼື ການໃຊ້ mDL ຍົກເວັ້ນໃນກໍລະນີທີ່ກົດໝາຍກຳນົດ
• W3C: ຊໍ່ຟຣ຺ວ ຂອງຜູ້ຖືໃບຢັ້ງຢືນຄວນໃຫ້ບັນທຶກຂໍ້ມູນທີ່ແບ່ງປັນກັບຜູ້ຢືນຢັນ, ເພື່ອໃຫ້ສາມາດລະບຸການຮ້ອງຂໍທີ່ເກີນຂອບໄດ້
• EUDI: ຜູ້ໃຊ້ຄວນສາມາດເຂົ້າໃຊ້ບັນທຶກທຸລະກຳ, ລາຍງານການຮ້ອງຂໍທີ່ໜ້າສົງໄສ, ແລະ ຮ້ອງຂໍການລົບ

ໝວດໝູ່ການເກັບຮັກສາຄວນເປັນສ່ວນໜຶ່ງຂອງນະໂຍບາຍການເປີດເຜີຍຂໍ້ມູນຕົວເອງ:

• ຕຳຫຼວດລິມຖະໜົນ: ບໍ່ເກັບຮັກສາໂດຍຄ່າເລີ່ມຕົ້ນນອກຈາກບັນທຶກການດຳເນີນງານທີ່ຖືກຕ້ອງຕາມກົດໝາຍ
• ການກວດສອບລ່ວງໜ້າການເຊົ່າລົດ: ບັນທຶກທຸລະກຳທີ່ຜູກກັບການຈອງ, ບໍ່ແມ່ນສຳເນົາຕົວຕົນທີ່ໃຊ້ຄືນໄດ້
• ການປະຕິບັດຕາມຂໍ້ກຳນົດກອງລົດຂອງນາຍຈ້າງ: ບັນທຶກການປະຕິບັດຕາມ ຫຼື ຜົນການຢືນຢັນ, ບໍ່ແມ່ນຂໍ້ມູນໃບຢັ້ງຢືນດິບ
• ການຮ້ອງຮຽນປະກັນໄພ: ບັນທຶກການຮ້ອງຮຽນທີ່ຈຳກັດໃຫ້ກັບການຮ້ອງຮຽນ, ບໍ່ແມ່ນການເຂົ້າໃຊ້ຢ່າງຖາວອນ

IDP ໃນອະນາຄົດທີ່ບໍ່ສົນໃຈເລື່ອງການເກັບຮັກສາຂໍ້ມູນ ຈະຮັກສາຄວາມເປັນສ່ວນຕົວໄດ້ພຽງບາງສ່ວນ.

ສິ່ງທີ່ Wallet ຄວນຕັດສິນໃຈຈິງໆ

ຖ້າຂ້ອຍຕ້ອງຫຍໍ້ບົດຄວາມທັງໝົດນີ້ໃຫ້ເຫຼືອກົດລະບຽບການຈັດຕັ້ງປະຕິບັດດຽວ, ມັນຈະເປັນດັ່ງນີ້:

Wallet ບໍ່ຄວນຕອບ “ຂ້ອຍສາມາດນຳສະເໜີໃບຢັ້ງຢືນນີ້ໄດ້ບໍ?” ມັນຄວນຕອບ “ຂ້ອຍສາມາດນຳສະເໜີຊຸດຂໍ້ຮຽກຮ້ອງນີ້ໃຫ້ຜູ້ຢືນຢັນທີ່ພິສູດຕົວຕົນນີ້, ສຳລັບຈຸດປະສົງທີ່ຕັ້ງໃຈນີ້, ໃນສະພາບການນີ້, ພາຍໃຕ້ໝວດໝູ່ການເກັບຮັກສານີ້ໄດ້ບໍ?”

ການຕັດສິນໃຈນັ້ນຄວນຂັບເຄື່ອນດ້ວຍຂໍ້ມູນນຳເຂົ້າຢ່າງໜ້ອຍດັ່ງຕໍ່ໄປນີ້:

• ຕົວຕົນຜູ້ຢືນຢັນ
• ໝວດໝູ່ຜູ້ຢືນຢັນ
• ຈຸດປະສົງການໃຊ້ງານ
• ຂອບເຂດຄຸນລັກສະນະທີ່ລົງທະບຽນ
• ນະໂຍບາຍການເປີດເຜີຍຂໍ້ມູນຈາກຜູ້ອອກ, ຖ້າມີ
• ສິ່ງແວດລ້ອມ (ລິມຖະໜົນ, ເວລາຮັບລົດ, ທາງໄກ, ກອງລົດ, ການຮ້ອງຮຽນ)
• ການອະນຸມັດຂອງຜູ້ຖືໃບຢັ້ງຢືນ
• ນະໂຍບາຍການເກັບຮັກສາທີ່ໃຊ້ໄດ້

ມາດຕະຖານໄດ້ມີກົນໄກຫຼາຍຢ່າງສຳລັບສິ່ງນີ້ຢູ່ແລ້ວ: ການເປີດເຜີຍຂໍ້ມູນແບບຄັດເລືອກ, ການພິສູດຕົວຕົນ Relying Party, ຈຸດປະສົງການໃຊ້ງານທີ່ລົງທະບຽນ, ໃບຢັ້ງຢືນການເຂົ້າໃຊ້, ການປະເມີນນະໂຍບາຍການເປີດເຜີຍຂໍ້ມູນ, ແລະ ການຮ້ອງຂໍທີ່ຜູກກັບຈຸດປະສົງ. ສິ່ງທີ່ຍັງຂາດຢູ່ຄືວິທີຢ່າງຮັດກຸມໃນການປະຕິບັດຊິ້ນສ່ວນເຫຼົ່ານັ້ນໃນຖານະສະຖາປັດຕະຍະກຳການເປີດເຜີຍຂໍ້ມູນທີ່ສອດຄ່ອງ.

ຂໍ້ໂຕ້ແຍ້ງຫຼັກ

IDP ໃນອະນາຄົດຄວນບໍ່ຖາມວ່າຂໍ້ມູນສາມາດຖືກເປີດເຜີຍໄດ້ຫຼືບໍ່. ມັນຄວນຖາມ:

• ໃຜ ກຳລັງຖາມ?
• ເພື່ອຈຸດປະສົງໃດ?
• ພາຍໃຕ້ ອຳນາດໃດ?
• ໃນສະພາບການໃດ?
• ດ້ວຍຜົນຕາມມາດ້ານການເກັບຮັກສາແນວໃດ?

ຕຳຫຼວດ, ໂຕ໊ະເຊົ່າລົດ, ນາຍຈ້າງ, ແລະ ບໍລິສັດປະກັນໄພ ບໍ່ແມ່ນສີ່ໂລໂກ້ຢູ່ອີກຝ່າຍໜຶ່ງຂອງການຮ້ອງຂໍ. ພວກເຂົາເປັນສີ່ຮູບແບບຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນ, ສີ່ສະພາບການທາງກົດໝາຍທີ່ແຕກຕ່າງກັນ, ສີ່ເຫດຜົນທີ່ຕ່າງກັນໃນການຖາມ — ແລະ ພວກເຂົາຄວນສ້າງຊຸດການເປີດເຜີຍຂໍ້ມູນສີ່ຊຸດທີ່ແຕກຕ່າງກັນ.

ນັ້ນບໍ່ແມ່ນຄວາມສັບສົນທີ່ບໍ່ຈຳເປັນ. ນັ້ນຄືສິ່ງທີ່ໃບຢັ້ງຢືນການຂັບລົດສະໄໝໃໝ່ຄວນເປັນ ເມື່ອມັນຢຸດປະຕິບັດຕໍ່ຜູ້ຢືນຢັນທຸກຄົນຄືກັນ.