Гэртээ Залгах Баталгаажуулалтгүй: Ирээдүйн Дижитал Олон Улсын Жолооны Үнэмлэх Яагаад Ашиглах Болгон Олгогч Руу Хандах Ёсгүй Вэ

Хүчингүй болгох нь ирээдүйн дижитал олон улсын жолооны үнэмлэхийн (IDP) хамгийн хэцүү асуудал юм. Үүнийг шийдвэрлэх хамгийн хялбар арга нь мөн хамгийн аюултай нь: олгогчийг итгэмжлэлийг дэвшүүлэн харуулах болгон оролцуулах явдал юм. Орчин үеийн хил дамнасан жолооны итгэмжлэл үндсэндээ энэ товчлолоос татгалзах ёстой.

Бараг бүх дижитал таних тэмдгийн санал нэг ижил тайвшруулах өгүүлбэрийг агуулдаг:

“Итгэмжлэлийг шууд баталгаажуулж болно.”

Заримдаа энэ өгүүлбэр жинхэнэ дэвшлийг дүрслэдэг. Заримдаа хэрэглэгчийн интерфэйс илүү найрсаг болсон тандалтыг дүрсэлдэг.

Өнөөдрийн нийтэлсэн стандартууд нь баталгаажуулагч итгэмжлэлийг ашиглах болгон олгогч руу хандах шаардлагагүй гэдгийг аль хэдийн тодорхой болгосон:

• NIST-ийн одоогийн mDL архитектур нь баталгаажуулагч олгогчтой шууд холбоогүйгээр олгогчийн гарын үсэг болон нийтийн түлхүүрт найдан жинхэнэ байдал, бүрэн бүтэн байдлыг баталгаажуулж болно гэж заасан.
• AAMVA нь ISO/IEC 18013-5 нь төхөөрөмжийн авах горимыг дэмжихийг шаарддаг бөгөөд зөвхөн сонголтоор серверийн авах горимыг зөвшөөрдөг гэдгийг баталж байна.
• AAMVA мөн анхааруулж байна — серверийн авах горимын хувьд олгох байгууллага ашиглах болгон бодит цаг хугацаанд оролцдог — энэ нь техникийн хувьд итгэмжлэл хэзээ ашиглагдсан, ямар өгөгдөл хуваалцсан, IP шинжилгээгээр байршлыг ч таамаглах боломжтой гэсэн үг.

Энэ нь жижиг тайлбарын тэмдэглэл биш юм. Энэ нь хил дамнасан жолооны итгэмжлэлийн дараагийн үеийн төв дизайны асуулт юм.

Аюултай Товчлол: Дөрвөн Асуултыг Нэг Сүлжээний Дуудлагад Нэгтгэх

Муу архитектурууд дөрвөн өөр асуултыг олгогч руу нэг шууд дуудлагад нэгтгэдэг:

1. Энэ итгэмжлэл жинхэнэ мөн үү?
2. Үүнийг дэвшүүлж байгаа хүн хууль ёсны эзэмшигч мөн үү?
3. Итгэмжлэл өөрөө хүчин төгөлдөр байна уу?
4. Үндсэн улсын жолоодох эрх одоо хүчин төгөлдөр байна уу?

Муу дизайны систем дөрвийг нь гэртээ бодит цаг хугацаанд залгаж шийддэг. Сайн дизайны систем тэдгээрийг тусдаа авч үздэг — учир нь эдгээр нь ижил асуудал биш бөгөөд нэг механизм хуваалцах ёсгүй.

Жинхэнэ Байдлыг Сүлжээгээр Биш, Нутгийн Түвшинд Баталгаажуулах Ёстой

Итгэмжлэл нь гүйлгээг олгогч хэзээ ч ажигламасан байхад криптографийн хувьд жинхэнэ байж болно.

• NIST-ийн mDL итгэлцлийн загвар нь жинхэнэ байдал, бүрэн бүтэн байдлыг олгогчийн гарын үсэг болон нийтийн түлхүүрээр баталгаажуулдаг — олгогчтой шууд холбоо шаардагдахгүй.
• AAMVA-ийн Дижитал Итгэлцлийн Үйлчилгээ нь баталгаажуулагчдад тухайн гүйлгээ тутам буцаан залгалгүйгээр хүчин төгөлдөр олгогчийн нийтийн түлхүүрт нэвтрэх боломж олгох зорилгоор оршин байдаг.

Дизайны зарчим 1: Гарын үсэг аль хэдийн шийддэг асуудлыг шийдвэрлэхийн тулд шууд холболт ашиглах хэрэггүй.

Хэрэв баталгаажуулагч итгэмжлэгдсэн олгогчийн түлхүүртэй бөгөөд стандартад нийцсэн дэвшүүлэлтийг хүлээн авбал жинхэнэ байдал нь нутгийн криптографийн шалгалт бөгөөд сүлжээний хамаарал биш юм.

Эзэмшигчийн Холбоог Нутгийн Түвшинд Батлах Ёстой, Дэлхий Нийтэд Мэдэгдэх Биш

Хоёр дахь асуулт — энэ нь хууль ёсны эзэмшигч мөн үү? — мөн сүлжээний бус хариулттай.

Одоогийн EUDI архитектур нь PID болон ISO/IEC 18013-5 гэрчилгээнүүдийн хувьд төхөөрөмжийн холбоог заавал гэж тодорхойлдог. Баталгаажуулагч нь итгэмжлэлд суулгагдсан нийтийн түлхүүртэй тохирох хувийн түлхүүр ашиглан шинэ сорилтыг гарын үсгээр баталгаажуулахыг хүснэ:

• ISO/IEC 18013-5-д энэ нь mdoc authentication гэж нэрлэгддэг.
• SD-JWT VC-д энэ нь key binding гэж нэрлэгддэг.

Хоёр тохиолдолд хоёулаа эзэмшлийг нутгийн түвшинд криптографийн аргаар баталдаг. Хувийн өгөгдөл хэзээ ч олгогч руу хүрэх шаардлагагүй.

Дизайны зарчим 2: Эзэмшлийг нутгийн түвшинд батал. Таних тэмдгийг дэлхий нийтэд батлах хэрэггүй.

Ирээдүйн IDP нь олгогчийн талаас ямар нэгэн механизмыг авч үзэхийн өмнө төхөөрөмжийн холбоо, нутгийн эзэмшигчийн баталгаажуулалт, баталгаажуулагчийн сорилт-хариу процессыг бүрэн ашиглах ёстой.

Итгэмжлэлийн Төлөв болон Жолооны Эрхийн Төлөв Хоёр Өөр Зүйл

Олон дижитал таних тэмдгийн дизайн энэ ялгааг бүдгэрүүлдэг бөгөөд тэд яг тэнд алдаа гаргадаг.

W3C-ийн Bitstring Status List тодорхойлолт энэ цэгийг тодорхой хэлсэн: баталгаажуулагдах итгэмжлэлд хавсаргасан төлвийн мэдээлэл нь баталгаажуулагдах итгэмжлэлд өөрт нь хамаатай — заавал доорх бодит ертөнцийн эрхэд хамаарах шаардлагагүй. Дижитал итгэмжлэл нь гарын үсгийн механизм хагарсны улмаас хүчингүй болж болох бол үндсэн жолооны эрх бүрэн хүчин төгөлдөр хэвээр байж болно.

Тиймийн тул ирээдүйн IDP нь хоёр тусдаа төлвийн давхарга шаарддаг:

• Итгэмжлэлийн төлвийн давхарга — дижитал итгэмжлэл буюу дэвшүүлэлтийн сувгийн хувьд.
• Жолооны эрхийн давхарга — жолоодох үндсэн үндэсний эрхийн хувьд.

Заримдаа эдгээр нь хамт өөрчлөгддөг. Ихэнхдээ тийм байдаггүй. Тэдгээрийг хольж холбох систем хэт хурдан хариу үзүүлэх, шаардлагаас илүү өгөгдөл задруулах, эсвэл хоёуланг нь хийх болно.

Түрийвчний Компромисс Төлвийн Дамжуулалтаар Тархах Ёстой — Баталгаажуулагчийн Буцаан Залгалтыг Өдөөх Биш

Ирээдүйн IDP нь мөн түрийвч компромисст орвол юу болохын тухай цэвэрхэн хариулттай байх ёстой.

EUDI архитектур нэгийг өгдөг:

• Түрийвчний үйлчилгээ үзүүлэгч нь хүчингүй болгох мэдээлэл агуулсан Түрийвчний Нэгжийн Гэрчилгээ олгодог.
• Түрийвчний бүрэн бүтэн байдлыг цаг хугацааны явцад дахин баталгаажуулдаг; хэрэв түрийвч аюулгүй биш бол түүний гэрчилгээ хүчингүй болдог.
• PID үйлчилгээ үзүүлэгчид түрийвч хүчингүй болсон эсэхийг тогтмол шалгах ёстой. Тийм бол тэд PID-ийг хүчингүй болгодог.
• PID төлвийг баталгаажуулснаар найдах тал шууд бусаар түрийвчний төлвийг баталгаажуулдаг.

Энэ бол ирээдүйн IDP авах ёстой давхаргалалт юм. Бүх баталгаажуулагчаас түрийвчний үйлчилгээ үзүүлэгчийг бие даан шалгахыг бүү хүс. Түрийвчний компромиссыг одоо байгаа итгэмжлэлийн төлвийн дамжуулалтаар нэвчүүлж, баталгаажуулагчдад тэр нэг нууцлалыг хамгаалсан суваг ашиглуулах.

Гурван Ажиллагаатай Хүчингүй Болгох Загвар (Буцаан Залгалтгүй)

EUDI нь үйлчилгээ үзүүлэгчдэд гурван хүчингүй болгох аргын аль нэгийг ашиглахыг шаарддаг:

• Богино хугацааны гэрчилгээнүүд — 24 цаг буюу түүнээс бага хугацаанд хүчин төгөлдөр, тиймийн тул хүчингүй болгох шаардлагагүй болдог.
• Гэрчилгээний Төлвийн Жагсаалт — баталгаажуулагчид лавлах боломжтой нийтлэгдсэн жагсаалт.
• Гэрчилгээний Хүчингүй Болгох Жагсаалт — хүчингүй болсон итгэмжлэлүүдийн тодорхой жагсаалт.

24 цагаас урт хугацаанд хүчин төгөлдөр гэрчилгээнүүдийн хувьд EUDI нь дараахийг агуулсан хүчингүй болгох мэдээллийг суулгахыг шаарддаг:

• Найдах талууд төлвийн жагсаалтыг авах боломжтой URL.
• Тухайн жагсаалт дахь итгэмжлэлийг тодорхойлох мэдээлэл.

Хэрэв найдвартай хүчингүй болгох мэдээлэл байхгүй бол — жишээлбэл, найдах тал офлайн байх үед — EUDI найдах талыг итгэмжлэлийг зөвшөөрөх эсвэл татгалзахаасаа өмнө эрсдлийн шинжилгээ хийхийг зааварчилдаг.

Хэлэх ёстой зүйл: хүчингүй болгох нь нэг механизм биш бөгөөд заавал олгогчийн буцаан залгалтын зөвтгөл биш юм.

Үндсэндээ Богино Хугацааны, Зөвхөн Шаардлагатай Газар Урт Хугацааны

Бүх стекийн хамгийн үр дүнтэй нууцлалын арга хамгийн энгийн нь: дэвшүүлж буй зүйлийг богино хугацааны байлга.

• EUDI нь 24 цаг буюу түүнээс бага хугацааны гэрчилгээнүүд хүчингүй болгох дэд бүтэц шаарддаггүй гэж хэлдэг — тэд хүчингүй болгох нь чухал болохоос өмнө хугацаа дуусдаг.
• W3C нь баталгаажуулагдах дэвшүүлэлтүүд ихэвчлэн богино хугацааны бөгөөд урт хугацааны хадгалалтад зориулагдаагүй гэж хэлдэг.
• NIST нь өдөр тутмын хэрэглээнд дахин ашиглах боломжтой тодорхойлогчийг давтан дамжуулахгүй байхыг тодорхой анхааруулдаг. Өдөр тутмын баталгаажуулалт нь таних тэмдгийн баялаг итгэмжлэлийг давтан дэвшүүлэхийн оронд passkeys гэх мэт зориулалтын технологид тулгуурлах ёстой.
• NIST мөн нууцлалыг хамгаалж, үйл ажиллагааны хувьд илүү үр ашигтай учраас сервер талын биометрийн тааруулалтын оронд нутгийн төхөөрөмжийн баталгаажуулалтыг сонгосон.

Дизайны зарчим 3: Үндсэн итгэмжлэл дунд зэргийн хүчин хугацаатай байж болох ч дэвшүүлэлт өөрөө богино хугацааны, баталгаажуулагч-тусгай, дахин ашиглах боломжгүй байх ёстой.

Төлвийн Жагсаалт бол Зөв Үндсэн Механизм

Бүх зүйлийг богино хугацааных болгох боломжгүй бол төлвийн дэд бүтэц хэрэгтэй — бөгөөд төлвийн жагсаалт нь зөв үндсэн сонголт юм.

W3C-ийн Bitstring Status List v1.0 нь түдгэлзүүлэх буюу хүчингүй болгох зэрэг төлвийн өгөгдлийг нийтлэхийн тулд нууцлалыг хамгаалсан, орон зайн хувьд үр ашигтай, өндөр гүйцэтгэлтэй механизмыг тодорхойлдог. Гол шинж чанарууд нь:

• Олгогч тус бүр өөрийн олгосон итгэмжлэлүүдийн жагсаалтыг удирддаг.
• Ихэнх итгэмжлэл хүчингүй болдоггүй учир форматын шахалт сайтай.
• Үндсэн жагсаалтын хэмжээ нь 131,072 оруулга бөгөөд W3C энэ нь дундаж тохиолдолд хангалттай бүлгийн нууцлал хангадаг гэж хэлдэг.
• Илүү хүчтэй бүлгийн нууцлал шаардлагатай газарт том жагсаалтыг ашиглаж болно.

Энэ нь асуултыг:

“Энэ хэрэглэгчийн тухай одоо олгогчоос асуух боломжтой юу?”

гэснээс:

“Нутгийн түвшинд шийдвэр гаргахын тулд нууцлалыг хамгаалсан сүүлийн үеийн төлвийн жагсаалт надад аль хэдийн байна уу?”

гэс рүү шилжүүлдэг. Энэ нь техникийн болон улс төрийн хувьд хоёуланд нь илүү дээр асуулт юм.

“Гэртээ Залгахгүй” бол Татаж Авах Загвар, Уриа Биш

EUDI-ийн нууцлалын удирдамж дахь хамгийн чухал дүрэм нь гүн ухааны биш, процедурын шинжтэй.

Найдах талууд итгэмжлэлийг ашиглах болгон төлвийн жагсаалтыг хүсэх ёсгүй. Харин тэд:

• Жагсаалтын шинэ хувилбар тус бүрийг нэг удаа татаж авах.
• Үүнийг хэрэглэгчийн ямар ч дэвшүүлэлттэй холбоогүй цаг хугацаанд болон байршлаас хийх.
• Жагсаалтыг найдах талын байгууллагад дотооддоо тараах.
• Найдах талыг баталгаажуулалтгүйгээр жагсаалтыг авах.

Энэ бол гэртээ залгахгүй баталгаажуулалтын үйл ажиллагааны гол цөм юм: төлвийг хэрэглэгчийн дэвшүүлэлтээс тусдаа шинэчил — хэзээ ч хүн тус бүрт, хэзээ ч гүйлгээ тус бүрт биш.

Энэ нэг дизайны сонголт нь олгогч буюу төлвийн үйлчилгээ үзүүлэгч аль баталгаажуулагч аль итгэмжлэлийг аль мөчид шалгасныг мэдэхээс сэргийлдэг.

Бүлгийн Нууцлал: Ихэнх Дизайн Мартдаг Шаардлага

Олон систем дэвшүүлэлт дотор сонгомол задруулалтыг зарладаг, дараа нь төлвийн хайлтын нууцлалыг чимээгүйхэн үл тоомсорлодог. Энэ нь чухал дутагдал юм.

EUDI-ийн нууцлалын шаардлагууд нь дараахийг тодорхойлсон:

• Төлвийн жагсаалт дахь индексүүдийг санамсаргүй байдлаар томилох ёстой, тиймийн тул индекс өөрөө хяналтын дохио болж хувирдаггүй.
• Жагсаалт тус бүр бүлгийн нууцлалыг хангахын тулд хангалттай том тооны итгэмжлэлийг хамрах ёстой.
• Хэрэв жагсаалт хэтэрхий жижиг болох байсан бол үйлчилгээ үзүүлэгчид жинхэнэ итгэмжлэлийн тоог нуухын тулд ашиглагдаагүй оруулгуудыг нэмэх ёстой.

Ирээдүйн IDP нь зөвхөн сонгомол задруулалтын давуу талд тулгуурлан нууцлалыг хамгаалдаг гэж мэдэгдэх боломжгүй. Хэрэв хүчингүй болгох механизм дэвшүүлэлтийн үйл явдлыг задруулвал нууцлалын дизайн дутуу байна.

Офлайн Ажиллагаа нь Захын Тохиолдол Биш — Энэ бол Үндсэн Шаардлага

Төгс холболт байна гэж таамаглах аялалын систем муу дизайнтай.

• AAMVA нь төхөөрөмжийн авах горим эзэмшигчийн төхөөрөмж болон уншигч хоёуланд нь гадаад холболтгүйгээр ажилладаг гэдгийг баталж, ISO/IEC 18013-5 нь mDL-үүдэд төхөөрөмжийн авах горимыг дэмжихийг шаарддаг гэж хэлдэг.
• EUDI нь найдах талууд офлайн байж кэшлэгдсэн төлвийн жагсаалтгүй байж болохыг хүлээн зөвшөөрч, тийм тохиолдолд шийдвэр гаргахаасаа өмнө эрсдлийн шинжилгээ хийхийг зөвлөдөг.

Энэ солилцооны харьцааг эрт хүлээн зөвшөөр:

Нэгэн зэрэг төгс офлайн ажиллагаа болон төгс бодит цагийн шинэлэг байдалтай байж чадахгүй.

Хоёулааг нь буулт хийлгүйгээр амлаж байгаа аливаа архитектур нь нарийн биш эсвэл чимээгүйхэн тандалтыг дахин нэвтрүүлж байна. Зөв хариу нь шинэлэг байдлыг бүх нийтийн сүлжээний хамаарал биш, бодлогын оролт болгох явдал юм.

Лог нь Нууцлал Чимээгүйхэн Бүтэлгүйтэх Газар

Гайхалтай төлвийн архитектурыг ч болгоомжгүй нэвтрэлтийн мэдээлэл бичлэг болгох нь сэтгэл санааны дарамт болж болно.

• EUDI нь найдах талын тохиолдлуудаас өвөрмөц элементүүд болон цаг тэмдэглэлийг шаардлагагүй болмогц устгахыг шаарддаг бөгөөд тэдгээрийг дамжуулахыг хориглодог.
• AAMVA нь оролцогч талуудыг mDL эзэмшигчдийг буюу mDL хэрэглээг хуулиар шаардагдсаас бусад тохиолдолд хянахыг хориглодог, олгох байгууллагаас статик буюу урт хугацааны мета өгөгдлийг хуваалцахыг нь багасгахыг шаарддаг бөгөөд үйл ажиллагааны лог руу нэвтрэх эрхийг зөвхөн эзэмшигчид хязгаарладаг.
• AAMVA мөн төхөөрөмж дээрх устгал нь хэрэглээний түүхийг илчилж болох лог мэдээлэл болон мета өгөгдлийг устгах ёстой гэж шаарддаг — мөн энэ устгал офлайн горимд боломжтой байх ёстой.

Энэ нь протоколын зан төлөв бөгөөд захиргааны ажил биш юм. Ирээдүйн IDP нь урт хугацааны тодорхойлогч, цаг тэмдэглэл, логуудыг тусгайлан батлагдаагүй бол боломжит хяналтын хэрэгслүүд гэж үзэх ёстой.

Ирээдүйн IDP-д Зориулсан Тодорхой Гэртээ Залгахгүй Архитектур

Зарчмуудыг нэгтгэвэл, систем үнэхээр юу хийх ёстойг энд харуулав:

1. Төхөөрөмжтэй холбосон үндсэн итгэмжлэл олгох. Итгэмжлэлийг түрийвчний аюулгүй орчинд хамгаалагдсан түлхүүрүүдтэй холбох — EUDI-д PID болон ISO/IEC 18013-5 гэрчилгээнүүдийн хувьд заавал.
2. Зөвхөн шаардлагатай зүйлийг шинэ сорилтоор хүс. OpenID4VP гүйлгээнд DCQL хүсэлт нь эзэмшигчид ямар шинж тэмдгүүдийг хүсэж байгааг харуулах боломжийг олгодог бөгөөд баталгаажуулагч тоглуулт давтахаас сэргийлэхийн тулд сорилт гаргадаг (NIST-ийн одоогийн mDL архитектурын дагуу).
3. Дахин ашиглах боломжтой тодорхойлогч биш, богино хугацааны дэвшүүлэлт үүсгэх. Дэвшүүлэлт тус бүр баталгаажуулагч, хүсэлт болон мөчид тусгай байх ёстой.
4. Жинхэнэ байдлыг нутгийн түвшинд баталгаажуулах. Олгогчийн гарын үсэг болон нийтийн түлхүүрийг офлайн горимд шалгах; AAMVA-ийн итгэлцлийн үйлчилгээ яг ийм зорилгоор бүтээгдсэн.
5. Тусдаа шинэчлэгдсэн кэшлэгдсэн жагсаалтаас төлвийг шалгах. Хэрэв итгэмжлэлүүд хүчингүй болгохыг алгасахад хэтэрхий урт хугацааных бол хэрэглэгчийн дэвшүүлэлттэй холбоогүй хуваарийн дагуу шинэчлэгдсэн нутгийн кэшлэгдсэн төлвийн жагсаалтуудыг ашиглах.
6. Шинэлэг байдал байхгүй үед эрсдлийн бодлого хэрэгжүүлэх. Офлайн шийдвэрүүдийг бүтэцгүй таамаглал биш тодорхой баталгаажуулагчийн бодлого болго.
7. Хяналтын өгөгдлийг идэвхтэйгээр устгах. Гүйлгээнд өвөрмөц элементүүд болон цаг тэмдэглэлийг шаардлагагүй болмогц устга; хөдөлгөөний түүхийг сэргээж болох логуудыг хадгалахгүй байх.

Энэ бол ноцтой гэртээ залгахгүй архитектур ямар харагдах ёстой вэ — давхаргалсан, нууцлалыг хамгаалсан, криптографийн хувьд нутгийн, офлайн бодит байдлын талаар үйл ажиллагааны хувьд шударга.

Дизайнаар Хориглох Ёстой Гурван Загвар

Боловсорсон ирээдүйн IDP экосистем эдгээрийг оновчлолын сонголт биш, архитектурын алдаа гэж үзэх ёстой:

• Дэвшүүлэлт болгон заавал олгогчийн буцаан залгалт. AAMVA-ийн өөрийн нууцлалын удирдамж яагаад энэ нь хортой болохыг тайлбарладаг.
• Жолооны итгэмжлэлийг ердийн нэвтрэлт болгон ашиглах. NIST нь өдөр тутмын баталгаажуулалтад таних тэмдгийг агуулсан итгэмжлэлийг давтан дэвшүүлэхийн эсрэг тодорхой анхааруулдаг.
• Дэвшүүлэлтийн түүхийг сэргээж болох тодорхойлогч, цаг тэмдэглэл, логуудыг хадгалах. EUDI болон AAMVA хоёулаа эсрэгийг шаарддаг.

Нэг Өгүүлбэрт Гол Маргаан

Шуурхай баталгаажуулалт нь олгогчийн талаас тандах зөвшөөрөл болж хувирах ёсгүй.

Ирээдүйн IDP дараахийг хийх чадвартай байх ёстой:

• Жинхэнэ байдлыг нутгийн түвшинд батлах.
• Эзэмшлийг нутгийн түвшинд батлах.
• Шинэлэг байдлыг нууцлалтайгаар шалгах.
• Офлайн бодит байдлыг тэвчих.
• Төгс мэдээлэл байхгүй үед уян хатан ажиллах.

Эдгээрийн аль нь ч системийг сулруулдаггүй. Харин томоохон хэмжээнд нэвтрүүлэхэд зохистой болгодог.

Жолооны итгэмжлэл хэн юуг хаана хэзээ үзүүлсэн бэ гэдгийг бичлэглэх хэрэгсэл болох мөчид тэр цаасан хувилбараас аюулгүй хувилбар болохоо зогсооно. Энэ нь хяналтын дэд бүтэц болно.

Ирээдүйн IDP яг тэр болж хувирахаас татгалзах ёстой.

Түгээмэл Асуултууд

“Гэртээ залгах баталгаажуулалт” гэж юу вэ?
Энэ нь баталгаажуулагч итгэмжлэлийг баталгаажуулахын тулд бодит цаг хугацаанд олгогч руу хандах ямар ч дизайн юм. Жинхэнэ байдал болон хүчингүй болгохыг нэгэн зэрэг шийддэг ч олгогчид бүх дэвшүүлэлтийн үйл явдлыг ажиглах боломж олгодог.

ISO/IEC 18013-5 онлайн олгогчийн холбоо шаарддаг уу?
Үгүй. AAMVA нь ISO/IEC 18013-5 нь төхөөрөмжийн авах горимыг дэмжихийг шаарддаг бөгөөд зөвхөн сонголтоор серверийн авах горимыг зөвшөөрдөг гэдгийг баталдаг.

Олгогч руу хандалгүйгээр хүчингүй болгох яаж ажиллах вэ?
Богино хугацааны итгэмжлэл, гэрчилгээний төлвийн жагсаалт, эсвэл гэрчилгээний хүчингүй болгох жагсаалтаар — хамгийн тохиромжтой нь найдах тал хэрэглэгчийн дэвшүүлэлтээс тусдаа төлвийн өгөгдлийг татаж авснаар.

Яагаад “бүлгийн нууцлал” төлвийн жагсаалтад чухал вэ?
Хэрэв төлвийн жагсаалт хэтэрхий жижиг эсвэл индексүүд нь таамаглах боломжтой бол төлвийн хүсэлт аль тусгай итгэмжлэлийг дөнгөж үзүүлсэн болохыг задруулж болно. Санамсаргүй индексүүд болон том жагсаалтууд үүнийг сэргийлдэг.

Офлайн баталгаажуулалт үнэхээр боломжтой юу?
Тийм — мөн AAMVA болон EUDI зэрэг стандартын байгууллагууд үүнийг тодорхой шаарддаг. Солилцооны харьцаа нь төгс бодит цагийн шинэлэг байдал нь төгс офлайн ажиллагаатай нийцэхгүй тул шинэлэг байдал нь хатуу хамаарал биш бодлогын шийдвэр болох ёстой.