ਕੋਈ ਕਾਲ-ਹੋਮ ਤਸਦੀਕ ਨਹੀਂ: ਭਵਿੱਖ ਦੇ ਡਿਜੀਟਲ IDP ਨੂੰ ਹਰ ਵਰਤੋਂ 'ਤੇ ਜਾਰੀਕਰਤਾ ਨੂੰ ਫ਼ੋਨ ਕਿਉਂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ

ਕਿਸੇ ਵੀ ਭਵਿੱਖੀ ਡਿਜੀਟਲ ਅੰਤਰਰਾਸ਼ਟਰੀ ਡਰਾਈਵਿੰਗ ਪਰਮਿਟ (IDP) ਵਿੱਚ ਰੱਦ ਕਰਨਾ ਸਭ ਤੋਂ ਔਖੀ ਸਮੱਸਿਆ ਹੈ। ਇਸ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਸਭ ਤੋਂ ਖ਼ਤਰਨਾਕ ਵੀ ਹੈ: ਜਾਰੀਕਰਤਾ ਨੂੰ ਹਰ ਪੇਸ਼ਕਾਰੀ ਵਿੱਚ ਭਾਗੀਦਾਰ ਬਣਾਉਣਾ। ਇੱਕ ਆਧੁਨਿਕ ਸਰਹੱਦ ਪਾਰ ਡਰਾਈਵਿੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਇਸ ਸ਼ਾਰਟਕੱਟ ਤੋਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਨਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਲਗਭਗ ਹਰ ਡਿਜੀਟਲ-ਪਛਾਣ ਤਜਵੀਜ਼ ਵਿੱਚ ਇਹੀ ਭਰੋਸੇਯੋਗ ਵਾਕ ਹੁੰਦਾ ਹੈ:

“ਪ੍ਰਮਾਣ-ਪੱਤਰ ਤੁਰੰਤ ਤਸਦੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।”

ਕਈ ਵਾਰ ਇਹ ਵਾਕ ਅਸਲ ਤਰੱਕੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਕਈ ਵਾਰ ਇਹ ਇੱਕ ਵਧੇਰੇ ਸੁਹਾਵਣੇ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਨਾਲ ਨਿਗਰਾਨੀ ਦਰਸਾਉਂਦਾ ਹੈ।

ਅੱਜ ਦੇ ਪ੍ਰਕਾਸ਼ਿਤ ਮਿਆਰ ਪਹਿਲਾਂ ਹੀ ਸਪੱਸ਼ਟ ਕਰਦੇ ਹਨ ਕਿ ਇੱਕ ਤਸਦੀਕਕਾਰ ਨੂੰ ਹਰ ਵਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦਿਖਾਉਣ ਵੇਲੇ ਜਾਰੀਕਰਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ:

• NIST ਦਾ ਮੌਜੂਦਾ mDL ਢਾਂਚਾ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਤਸਦੀਕਕਾਰ ਜਾਰੀਕਰਤਾ ਦੇ ਦਸਤਖ਼ਤ ਅਤੇ ਜਨਤਕ ਕੁੰਜੀਆਂ ‘ਤੇ ਭਰੋਸਾ ਕਰਕੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਖੰਡਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ — ਜਾਰੀਕਰਤਾ ਨਾਲ ਕਿਸੇ ਸਿੱਧੇ ਸੰਪਰਕ ਤੋਂ ਬਿਨਾਂ।
• AAMVA ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ISO/IEC 18013-5 ਲਈ ਡਿਵਾਈਸ ਪ੍ਰਾਪਤੀ ਦੀ ਸਹਾਇਤਾ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਸਰਵਰ ਪ੍ਰਾਪਤੀ ਕੇਵਲ ਵਿਕਲਪਿਕ ਤੌਰ ‘ਤੇ ਹੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
• AAMVA ਇਹ ਵੀ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਪ੍ਰਾਪਤੀ ਅਧੀਨ, ਜਾਰੀ ਕਰਨ ਵਾਲੀ ਅਥਾਰਟੀ ਹਰ ਵਰਤੋਂ ‘ਤੇ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ — ਭਾਵ ਇਹ ਤਕਨੀਕੀ ਤੌਰ ‘ਤੇ ਦਰਜ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਕਦੋਂ ਵਰਤਿਆ ਗਿਆ, ਕਿਹੜਾ ਡੇਟਾ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ, ਅਤੇ IP ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਟਿਕਾਣਾ ਵੀ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੀ ਹੈ।

ਇਹ ਕੋਈ ਛੋਟੀ ਟਿੱਪਣੀ ਨਹੀਂ ਹੈ। ਇਹ ਸਰਹੱਦ ਪਾਰ ਡਰਾਈਵਿੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਅਗਲੀ ਪੀੜ੍ਹੀ ਲਈ ਕੇਂਦਰੀ ਡਿਜ਼ਾਈਨ ਸਵਾਲ ਹੈ।

ਖ਼ਤਰਨਾਕ ਸ਼ਾਰਟਕੱਟ: ਚਾਰ ਸਵਾਲਾਂ ਨੂੰ ਇੱਕ ਨੈੱਟਵਰਕ ਕਾਲ ਵਿੱਚ ਸਮੇਟਣਾ

ਮਾੜੇ ਢਾਂਚੇ ਚਾਰ ਬਿਲਕੁਲ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਨੂੰ ਜਾਰੀਕਰਤਾ ਨੂੰ ਇੱਕੋ ਲਾਈਵ ਕਾਲ ਵਿੱਚ ਬੰਨ੍ਹ ਦਿੰਦੇ ਹਨ:

1. ਕੀ ਇਹ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਸਲੀ ਹੈ?
2. ਕੀ ਇਸ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ ਅਸਲ ਧਾਰਕ ਹੈ?
3. ਕੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਖੁਦ ਅਜੇ ਵੀ ਵੈਧ ਹੈ?
4. ਕੀ ਅਧੀਨਲਾ ਰਾਸ਼ਟਰੀ ਡਰਾਈਵਿੰਗ ਅਧਿਕਾਰ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ?

ਮਾੜੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਸਿਸਟਮ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਘਰ ਫ਼ੋਨ ਕਰਕੇ ਚਾਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ — ਕਿਉਂਕਿ ਇਹ ਇੱਕੋ ਸਮੱਸਿਆ ਨਹੀਂ ਹਨ ਅਤੇ ਇਨ੍ਹਾਂ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਪ੍ਰਮਾਣਿਕਤਾ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਤਸਦੀਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨੈੱਟਵਰਕ ਉੱਤੇ ਨਹੀਂ

ਇੱਕ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ ‘ਤੇ ਅਸਲੀ ਹੋ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਜਾਰੀਕਰਤਾ ਕਦੇ ਲੈਣ-ਦੇਣ ਨਾ ਦੇਖੇ।

• NIST ਦਾ mDL ਭਰੋਸਾ ਮਾਡਲ ਕਹਿੰਦਾ ਹੈ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਖੰਡਤਾ ਜਾਰੀਕਰਤਾ ਦੇ ਦਸਤਖ਼ਤ ਅਤੇ ਜਨਤਕ ਕੁੰਜੀਆਂ ਤੋਂ ਤਸਦੀਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ — ਕਿਸੇ ਲਾਈਵ ਜਾਰੀਕਰਤਾ ਸੰਪਰਕ ਦੀ ਲੋੜ ਨਹੀਂ।
• AAMVA ਦੀ ਡਿਜੀਟਲ ਟਰੱਸਟ ਸੇਵਾ ਤਸਦੀਕਕਾਰਾਂ ਨੂੰ ਪ੍ਰਤੀ-ਲੈਣਦੇਣ ਕਾਲਬੈਕ ਤੋਂ ਬਿਨਾਂ ਵੈਧ ਜਾਰੀਕਰਤਾ ਜਨਤਕ ਕੁੰਜੀਆਂ ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਲਈ ਹੀ ਬਣਾਈ ਗਈ ਹੈ।

ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ 1: ਕਿਸੇ ਅਜਿਹੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਲਾਈਵ ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ ਜੋ ਦਸਤਖ਼ਤ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕਰਦੇ ਹਨ।

ਜੇ ਕੋਈ ਤਸਦੀਕਕਾਰ ਭਰੋਸੇਯੋਗ ਜਾਰੀਕਰਤਾ ਕੁੰਜੀਆਂ ਰੱਖਦਾ ਹੈ ਅਤੇ ਮਿਆਰਾਂ ਦੇ ਅਨੁਕੂਲ ਪੇਸ਼ਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਇੱਕ ਸਥਾਨਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਜਾਂਚ ਹੈ, ਨੈੱਟਵਰਕ ਨਿਰਭਰਤਾ ਨਹੀਂ।

ਧਾਰਕ ਬੰਧਨ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਸਾਬਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਵਿਸ਼ਵ ਪੱਧਰ ‘ਤੇ ਰਿਪੋਰਟ ਨਹੀਂ

ਦੂਜਾ ਸਵਾਲ — ਕੀ ਇਹ ਅਸਲ ਧਾਰਕ ਹੈ? — ਦਾ ਵੀ ਗੈਰ-ਨੈੱਟਵਰਕ ਜਵਾਬ ਹੈ।

ਮੌਜੂਦਾ EUDI ਢਾਂਚਾ PIDs ਅਤੇ ISO/IEC 18013-5 ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ ਲਈ ਡਿਵਾਈਸ ਬੰਧਨ ਲਾਜ਼ਮੀ ਕਰਦਾ ਹੈ। ਤਸਦੀਕਕਾਰ ਵਾਲਿਟ ਨੂੰ ਉਸ ਨਿੱਜੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਤਾਜ਼ਾ ਚੁਣੌਤੀ ‘ਤੇ ਦਸਤਖ਼ਤ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ ਜੋ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਿੱਚ ਏਮਬੈੱਡ ਜਨਤਕ ਕੁੰਜੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ:

• ISO/IEC 18013-5 ਵਿੱਚ ਇਸ ਨੂੰ mdoc ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
• SD-JWT VC ਵਿੱਚ ਇਸ ਨੂੰ ਕੁੰਜੀ ਬੰਧਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕਬਜ਼ਾ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਅਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ ‘ਤੇ ਸਾਬਿਤ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਨਿੱਜੀ ਡੇਟਾ ਕਦੇ ਜਾਰੀਕਰਤਾ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਲੋੜ ਨਹੀਂ।

ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ 2: ਕਬਜ਼ਾ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਸਾਬਿਤ ਕਰੋ। ਪਛਾਣ ਵਿਸ਼ਵ ਪੱਧਰ ‘ਤੇ ਸਾਬਿਤ ਨਾ ਕਰੋ।

ਭਵਿੱਖੀ IDP ਨੂੰ ਕਿਸੇ ਵੀ ਜਾਰੀਕਰਤਾ-ਪੱਖੀ ਵਿਧੀ ‘ਤੇ ਵਿਚਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਵਾਈਸ ਬੰਧਨ, ਸਥਾਨਕ ਧਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ, ਅਤੇ ਤਸਦੀਕਕਾਰ ਚੁਣੌਤੀ-ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਥਿਤੀ ਅਤੇ ਡਰਾਈਵਿੰਗ-ਅਧਿਕਾਰ ਸਥਿਤੀ ਦੋ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਹਨ

ਬਹੁਤ ਸਾਰੇ ਡਿਜੀਟਲ-ਪਛਾਣ ਡਿਜ਼ਾਈਨ ਇਸ ਫ਼ਰਕ ਨੂੰ ਧੁੰਦਲਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਥੇ ਹੀ ਉਹ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ।

W3C ਦੀ ਬਿਟਸਟ੍ਰਿੰਗ ਸਟੇਟਸ ਲਿਸਟ ਵਿਸ਼ੇਸ਼ਤਾ ਇਸ ਗੱਲ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ: ਇੱਕ ਤਸਦੀਕਯੋਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਾਲ ਜੁੜੀ ਸਥਿਤੀ ਜਾਣਕਾਰੀ ਤਸਦੀਕਯੋਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਖੁਦ ‘ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ — ਅਧੀਨਲੀ ਅਸਲ-ਸੰਸਾਰ ਦੀ ਹੱਕਦਾਰੀ ‘ਤੇ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਇੱਕ ਡਿਜੀਟਲ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਇਸ ਲਈ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦੀ ਦਸਤਖ਼ਤ ਵਿਧੀ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਦੋਂ ਕਿ ਅਧੀਨਲਾ ਡਰਾਈਵਿੰਗ ਅਧਿਕਾਰ ਬਿਲਕੁਲ ਵੈਧ ਰਹਿੰਦਾ ਹੈ।

ਇਸ ਲਈ ਭਵਿੱਖੀ IDP ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਸਥਿਤੀ ਪਰਤਾਂ ਦੀ ਲੋੜ ਹੈ:

• ਪ੍ਰਮਾਣ-ਪੱਤਰ-ਸਥਿਤੀ ਪਰਤ — ਡਿਜੀਟਲ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂ ਪੇਸ਼ਕਾਰੀ ਚੈਨਲ ਖੁਦ ਲਈ।
• ਡਰਾਈਵਿੰਗ-ਅਧਿਕਾਰ ਪਰਤ — ਡਰਾਈਵਿੰਗ ਦੀ ਅਧੀਨਲੀ ਰਾਸ਼ਟਰੀ ਹੱਕਦਾਰੀ ਲਈ।

ਕਈ ਵਾਰ ਇਹ ਇਕੱਠੇ ਬਦਲਦੇ ਹਨ। ਅਕਸਰ ਨਹੀਂ ਬਦਲਦੇ। ਜੋ ਸਿਸਟਮ ਇਨ੍ਹਾਂ ਨੂੰ ਰਲਗੱਡ ਕਰਦਾ ਹੈ ਉਹ ਜ਼ਿਆਦਾ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੇਗਾ, ਲੋੜ ਤੋਂ ਵੱਧ ਡੇਟਾ ਦੱਸੇਗਾ, ਜਾਂ ਦੋਵੇਂ।

ਵਾਲਿਟ ਸਮਝੌਤਾ ਸਥਿਤੀ ਰਾਹੀਂ ਫੈਲਣਾ ਚਾਹੀਦਾ ਹੈ — ਤਸਦੀਕਕਾਰ ਕਾਲਬੈਕ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ

ਭਵਿੱਖੀ IDP ਨੂੰ ਇਸ ਸਵਾਲ ਦਾ ਸਾਫ਼ ਜਵਾਬ ਵੀ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਦੋਂ ਵਾਲਿਟ ਨਾਲ ਸਮਝੌਤਾ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।

EUDI ਢਾਂਚਾ ਇੱਕ ਜਵਾਬ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

• ਵਾਲਿਟ ਪ੍ਰਦਾਤਾ ਵਾਲਿਟ ਯੂਨਿਟ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ ਜਾਰੀ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਰੱਦ ਕਰਨ ਦੀ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ।
• ਵਾਲਿਟ ਅਖੰਡਤਾ ਸਮੇਂ ਸਮੇਂ ‘ਤੇ ਮੁੜ-ਤਸਦੀਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਜੇ ਵਾਲਿਟ ਹੁਣ ਸੁਰੱਖਿਅਤ ਨਹੀਂ, ਤਾਂ ਇਸਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਰੱਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
• PID ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ ‘ਤੇ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਵਾਲਿਟ ਰੱਦ ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇ ਹਾਂ, ਤਾਂ ਉਹ PID ਰੱਦ ਕਰ ਦਿੰਦੇ ਹਨ।
• PID ਸਥਿਤੀ ਦੀ ਤਸਦੀਕ ਕਰਕੇ, ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ ਅਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਵਾਲਿਟ ਸਥਿਤੀ ਦੀ ਵੀ ਤਸਦੀਕ ਕਰਦੀ ਹੈ।

ਇਹੀ ਉਹ ਪਰਤਬੰਦੀ ਹੈ ਜੋ ਭਵਿੱਖੀ IDP ਨੂੰ ਅਪਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। ਹਰ ਤਸਦੀਕਕਾਰ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਵਾਲਿਟ ਪ੍ਰਦਾਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਨਾ ਕਹੋ। ਵਾਲਿਟ ਸਮਝੌਤੇ ਨੂੰ ਮੌਜੂਦਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ-ਸਥਿਤੀ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਫੈਲਣ ਦਿਓ, ਅਤੇ ਤਸਦੀਕਕਾਰਾਂ ਨੂੰ ਉਸ ਇੱਕਲੇ ਗੋਪਨੀਯਤਾ-ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਨਾਲ ਸਲਾਹ ਕਰਨ ਦਿਓ।

ਤਿੰਨ ਵਿਹਾਰਕ ਰੱਦ ਕਰਨ ਦੇ ਪੈਟਰਨ (ਕੋਈ ਕਾਲਬੈਕ ਲੋੜੀਂਦਾ ਨਹੀਂ)

EUDI ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਤਿੰਨ ਰੱਦ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਰਤਣ ਦੀ ਲੋੜ ਹੈ:

• ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀਆਂ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ — 24 ਘੰਟਿਆਂ ਜਾਂ ਘੱਟ ਲਈ ਵੈਧ, ਇਸ ਲਈ ਰੱਦ ਕਰਨਾ ਬੇਲੋੜਾ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਪ੍ਰਮਾਣਿਕਤਾ ਸਥਿਤੀ ਸੂਚੀ — ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਸੂਚੀ ਜਿਸ ਨਾਲ ਤਸਦੀਕਕਾਰ ਸਲਾਹ ਕਰ ਸਕਦੇ ਹਨ।
• ਪ੍ਰਮਾਣਿਕਤਾ ਰੱਦ ਕਰਨ ਸੂਚੀ — ਰੱਦ ਕੀਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਸਪੱਸ਼ਟ ਸੂਚੀ।

24 ਘੰਟਿਆਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਲਈ ਵੈਧ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ ਲਈ, EUDI ਨੂੰ ਏਮਬੈੱਡ ਰੱਦ ਕਰਨ ਦੀ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ:

• ਇੱਕ URL ਜਿੱਥੋਂ ਭਰੋਸਾ ਕਰਨ ਵਾਲੀਆਂ ਧਿਰਾਂ ਸਥਿਤੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।
• ਇੱਕ ਪਛਾਣਕਰਤਾ ਜੋ ਉਸ ਸੂਚੀ ਵਿੱਚ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਲੱਭਦਾ ਹੈ।

ਜੇ ਭਰੋਸੇਯੋਗ ਰੱਦ ਕਰਨ ਦੀ ਜਾਣਕਾਰੀ ਉਪਲਬਧ ਨਹੀਂ — ਉਦਾਹਰਣ ਵਜੋਂ, ਜਦੋਂ ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ ਔਫਲਾਈਨ ਹੋਵੇ — EUDI ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ ਨੂੰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਵੀਕਾਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹੈ।

ਸਿੱਖਿਆ: ਰੱਦ ਕਰਨਾ ਕੋਈ ਇੱਕਲਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਯਕੀਨਨ ਲਾਜ਼ਮੀ ਜਾਰੀਕਰਤਾ ਕਾਲਬੈਕ ਦਾ ਕੋਈ ਔਚਿੱਤ ਨਹੀਂ।

ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ, ਲੰਮੇ ਸਮੇਂ ਲਈ ਕੇਵਲ ਜਿੱਥੇ ਜ਼ਰੂਰੀ ਹੋਵੇ

ਪੂਰੇ ਸਟੈੱਕ ਵਿੱਚ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਗੋਪਨੀਯਤਾ ਉਪਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਭ ਤੋਂ ਸਰਲ ਵੀ ਹੈ: ਜੋ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇ ਉਸ ਨੂੰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਰੱਖੋ।

• EUDI ਕਹਿੰਦਾ ਹੈ ਕਿ 24 ਘੰਟਿਆਂ ਜਾਂ ਘੱਟ ਲਈ ਵੈਧ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ ਲਈ ਰੱਦ ਕਰਨ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਨਹੀਂ — ਇਹ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਿਆਦ ਪੁੱਗ ਜਾਂਦੀਆਂ ਹਨ।
• W3C ਕਹਿੰਦਾ ਹੈ ਕਿ ਤਸਦੀਕਯੋਗ ਪੇਸ਼ਕਾਰੀਆਂ ਆਮ ਤੌਰ ‘ਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਲਈ ਸਟੋਰੇਜ ਲਈ ਨਹੀਂ ਬਣਾਈਆਂ ਗਈਆਂ।
• NIST ਰੋਜ਼ਮਰ੍ਹਾ ਦੀ ਵਰਤੋਂ ਲਈ ਮੁੜ-ਵਰਤੋਂਯੋਗ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਵਿਰੁੱਧ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਪਾਸਕੀਆਂ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ‘ਤੇ ਨਿਰਭਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਪਛਾਣ-ਭਰੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਵਾਰ-ਵਾਰ ਪੇਸ਼ਕਾਰੀ ‘ਤੇ।
• NIST ਨੇ ਸਰਵਰ-ਪੱਖੀ ਬਾਇਓਮੈਟ੍ਰਿਕ ਮਿਲਾਨ ਦੀ ਬਜਾਏ ਸਥਾਨਕ ਡਿਵਾਈਸ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਚੁਣਿਆ ਕਿਉਂਕਿ ਸਥਾਨਕ ਪ੍ਰਮਾਣਿਕਤਾ ਗੋਪਨੀਯਤਾ ਬਣਾਈ ਰੱਖਦੀ ਹੈ ਅਤੇ ਸੰਚਾਲਨ ਪੱਖੋਂ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ।

ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ 3: ਅਧਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਮੱਧਮ ਵੈਧਤਾ ਮਿਆਦ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਪੇਸ਼ਕਾਰੀ ਖੁਦ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ, ਤਸਦੀਕਕਾਰ-ਵਿਸ਼ੇਸ਼, ਅਤੇ ਮੁੜ-ਵਰਤੋਂਯੋਗ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਸਥਿਤੀ ਸੂਚੀਆਂ ਸਹੀ ਡਿਫੌਲਟ ਵਿਧੀ ਹਨ

ਜਦੋਂ ਤੁਸੀਂ ਸਭ ਕੁਝ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਨਹੀਂ ਬਣਾ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਥਿਤੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ — ਅਤੇ ਸਥਿਤੀ ਸੂਚੀ ਸਹੀ ਡਿਫੌਲਟ ਹੈ।

W3C ਦੀ ਬਿਟਸਟ੍ਰਿੰਗ ਸਟੇਟਸ ਲਿਸਟ v1.0 ਮੁਅੱਤਲੀ ਜਾਂ ਰੱਦ ਕਰਨ ਵਰਗੇ ਸਥਿਤੀ ਡੇਟਾ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਇੱਕ ਗੋਪਨੀਯਤਾ-ਸੁਰੱਖਿਅਤ, ਸਪੇਸ-ਕੁਸ਼ਲ, ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਿਧੀ ਦਰਸਾਉਂਦੀ ਹੈ। ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਹਰ ਜਾਰੀਕਰਤਾ ਆਪਣੇ ਜਾਰੀ ਕੀਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਲਈ ਇੱਕ ਸੂਚੀ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ।
• ਫਾਰਮੈਟ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਕੁਚਿਤ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਦ ਨਹੀਂ ਰਹਿੰਦੇ।
• ਡਿਫੌਲਟ ਸੂਚੀ ਆਕਾਰ 131,072 ਐਂਟਰੀਆਂ ਹੈ, ਜੋ W3C ਦੇ ਅਨੁਸਾਰ ਔਸਤ ਮਾਮਲੇ ਵਿੱਚ ਉਚਿਤ ਸਮੂਹ ਗੋਪਨੀਯਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
• ਜਿੱਥੇ ਮਜ਼ਬੂਤ ਸਮੂਹ ਗੋਪਨੀਯਤਾ ਦੀ ਲੋੜ ਹੋਵੇ, ਉੱਥੇ ਵੱਡੀਆਂ ਸੂਚੀਆਂ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਇਹ ਸਵਾਲ ਬਦਲਦਾ ਹੈ:

“ਕੀ ਮੈਂ ਹੁਣੇ ਇਸ ਉਪਭੋਗਤਾ ਬਾਰੇ ਜਾਰੀਕਰਤਾ ਤੋਂ ਪੁੱਛ ਸਕਦਾ ਹਾਂ?”

ਤੋਂ:

“ਕੀ ਮੇਰੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੱਕ ਕਾਫ਼ੀ ਤਾਜ਼ੀ ਗੋਪਨੀਯਤਾ-ਸੁਰੱਖਿਅਤ ਸਥਿਤੀ ਸੂਚੀ ਹੈ ਜਿਸ ਤੋਂ ਮੈਂ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਫ਼ੈਸਲਾ ਕਰ ਸਕਦਾ ਹਾਂ?”

ਇਹ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਸਵਾਲ ਹੈ — ਤਕਨੀਕੀ ਅਤੇ ਰਾਜਨੀਤਕ ਦੋਵੇਂ ਪੱਖਾਂ ਤੋਂ।

“ਕੋਈ ਕਾਲ-ਹੋਮ ਨਹੀਂ” ਇੱਕ ਡਾਊਨਲੋਡ ਪੈਟਰਨ ਹੈ, ਨਾਅਰਾ ਨਹੀਂ

EUDI ਦੀ ਗੋਪਨੀਯਤਾ ਮਾਰਗਦਰਸ਼ਨ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ ਦਾਰਸ਼ਨਿਕ ਨਹੀਂ, ਪ੍ਰਕਿਰਿਆਤਮਕ ਹੈ।

ਭਰੋਸਾ ਕਰਨ ਵਾਲੀਆਂ ਧਿਰਾਂ ਨੂੰ ਹਰ ਵਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪੇਸ਼ ਕੀਤੇ ਜਾਣ ‘ਤੇ ਸਥਿਤੀ ਸੂਚੀ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਇਸਦੀ ਬਜਾਏ, ਉਨ੍ਹਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ:

• ਸੂਚੀ ਦਾ ਹਰ ਨਵਾਂ ਸੰਸਕਰਨ ਇੱਕ ਵਾਰ ਡਾਊਨਲੋਡ ਕਰਨਾ।
• ਅਜਿਹਾ ਕਿਸੇ ਸਮੇਂ ਅਤੇ ਕਿਸੇ ਟਿਕਾਣੇ ਤੋਂ ਕਰਨਾ ਜੋ ਕਿਸੇ ਉਪਭੋਗਤਾ ਦੀ ਪੇਸ਼ਕਾਰੀ ਨਾਲ ਸੰਬੰਧਿਤ ਨਾ ਹੋਵੇ।
• ਸੂਚੀ ਨੂੰ ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ ਦੀ ਸੰਸਥਾ ਵਿੱਚ ਅੰਦਰੂਨੀ ਤੌਰ ‘ਤੇ ਵੰਡਣਾ।
• ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਬਿਨਾਂ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨੀ।

ਇਹੀ ਕੋਈ-ਕਾਲ-ਹੋਮ ਤਸਦੀਕ ਦਾ ਸੰਚਾਲਨ ਕੋਰ ਹੈ: ਸਥਿਤੀ ਨੂੰ ਉਪਭੋਗਤਾ ਦੀਆਂ ਪੇਸ਼ਕਾਰੀਆਂ ਤੋਂ ਵੱਖਰੇ ਤੌਰ ‘ਤੇ ਤਾਜ਼ਾ ਕਰੋ — ਕਦੇ ਵੀ ਪ੍ਰਤੀ ਵਿਅਕਤੀ, ਕਦੇ ਵੀ ਪ੍ਰਤੀ ਲੈਣ-ਦੇਣ ਨਹੀਂ।

ਇਹ ਇੱਕਲਾ ਡਿਜ਼ਾਈਨ ਚੋਣ ਜਾਰੀਕਰਤਾ ਜਾਂ ਸਥਿਤੀ ਪ੍ਰਦਾਤਾ ਨੂੰ ਇਹ ਜਾਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ ਕਿ ਕਿਸ ਤਸਦੀਕਕਾਰ ਨੇ ਕਿਸ ਪਲ ਕਿਹੜਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂਚਿਆ।

ਸਮੂਹ ਗੋਪਨੀਯਤਾ: ਉਹ ਲੋੜ ਜੋ ਜ਼ਿਆਦਾਤਰ ਡਿਜ਼ਾਈਨ ਭੁੱਲ ਜਾਂਦੇ ਹਨ

ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਪੇਸ਼ਕਾਰੀ ਦੇ ਅੰਦਰ ਚੋਣਵੇਂ ਖੁਲਾਸੇ ਦਾ ਢੋਲ ਪਿੱਟਦੇ ਹਨ, ਫਿਰ ਚੁੱਪਚਾਪ ਸਥਿਤੀ ਖੋਜ ਦੀ ਗੋਪਨੀਯਤਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਮੀ ਹੈ।

EUDI ਦੀਆਂ ਗੋਪਨੀਯਤਾ ਲੋੜਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ:

• ਸਥਿਤੀ ਸੂਚੀਆਂ ਵਿੱਚ ਸੂਚਕਾਂਕ ਬੇਤਰਤੀਬੇ ਨਿਰਧਾਰਿਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਜੋ ਸੂਚਕਾਂਕ ਖੁਦ ਕਦੇ ਟ੍ਰੈਕਿੰਗ ਸੰਕੇਤ ਨਾ ਬਣੇ।
• ਹਰ ਸੂਚੀ ਵਿੱਚ ਸਮੂਹ ਗੋਪਨੀਯਤਾ ਯਕੀਨੀ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਕਵਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
• ਜੇ ਕੋਈ ਸੂਚੀ ਬਹੁਤ ਛੋਟੀ ਹੋਵੇ, ਤਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਅਸਲ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਗਿਣਤੀ ਛੁਪਾਉਣ ਲਈ ਅਣਵਰਤੀਆਂ ਐਂਟਰੀਆਂ ਜੋੜਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਭਵਿੱਖੀ IDP ਕੇਵਲ ਚੋਣਵੇਂ ਖੁਲਾਸੇ ਦੇ ਅਧਾਰ ‘ਤੇ ਗੋਪਨੀਯਤਾ-ਸੁਰੱਖਿਅਤ ਹੋਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇ ਰੱਦ ਕਰਨ ਦੀ ਵਿਧੀ ਪੇਸ਼ਕਾਰੀ ਘਟਨਾ ਦਾ ਭੇਦ ਖੋਲ੍ਹਦੀ ਹੈ, ਤਾਂ ਗੋਪਨੀਯਤਾ ਡਿਜ਼ਾਈਨ ਅਧੂਰਾ ਹੈ।

ਔਫਲਾਈਨ ਸੰਚਾਲਨ ਕੋਈ ਸੀਮਾਂਤ ਕੇਸ ਨਹੀਂ — ਇਹ ਇੱਕ ਮੁੱਖ ਲੋੜ ਹੈ

ਕੋਈ ਵੀ ਯਾਤਰਾ ਸਿਸਟਮ ਜੋ ਸੰਪੂਰਨ ਕਨੈਕਟੀਵਿਟੀ ਮੰਨ ਕੇ ਚੱਲਦਾ ਹੈ, ਉਹ ਮਾੜੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੈ।

• AAMVA ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਡਿਵਾਈਸ ਪ੍ਰਾਪਤੀ ਧਾਰਕ ਡਿਵਾਈਸ ਅਤੇ ਰੀਡਰ ਦੋਵਾਂ ਲਈ ਬਾਹਰੀ ਕਨੈਕਟੀਵਿਟੀ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ISO/IEC 18013-5 mDLs ਨੂੰ ਡਿਵਾਈਸ ਪ੍ਰਾਪਤੀ ਦੀ ਸਹਾਇਤਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• EUDI ਮੰਨਦਾ ਹੈ ਕਿ ਭਰੋਸਾ ਕਰਨ ਵਾਲੀਆਂ ਧਿਰਾਂ ਔਫਲਾਈਨ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕੋਲ ਕੈਸ਼ਡ ਸਥਿਤੀ ਸੂਚੀ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਇਹ ਫ਼ੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ।

ਇਸ ਸਮਝੌਤੇ ਨੂੰ ਜਲਦੀ ਸਵੀਕਾਰ ਕਰੋ:

ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਸੰਪੂਰਨ ਔਫਲਾਈਨ ਸੰਚਾਲਨ ਅਤੇ ਸੰਪੂਰਨ ਅਸਲ-ਸਮੇਂ ਦੀ ਤਾਜ਼ਗੀ ਨਹੀਂ ਪਾ ਸਕਦੇ।

ਕੋਈ ਵੀ ਢਾਂਚਾ ਜੋ ਸਮਝੌਤੇ ਤੋਂ ਬਿਨਾਂ ਦੋਵਾਂ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਉਹ ਜਾਂ ਤਾਂ ਅਸਪੱਸ਼ਟ ਹੈ ਜਾਂ ਚੁੱਪਚਾਪ ਨਿਗਰਾਨੀ ਮੁੜ ਸ਼ਾਮਲ ਕਰ ਰਿਹਾ ਹੈ। ਸਹੀ ਜਵਾਬ ਇਹ ਹੈ ਕਿ ਤਾਜ਼ਗੀ ਨੂੰ ਇੱਕ ਨੀਤੀ ਇਨਪੁੱਟ ਬਣਾਇਆ ਜਾਵੇ, ਸਰਵਵਿਆਪੀ ਨੈੱਟਵਰਕ ਨਿਰਭਰਤਾ ਨਹੀਂ।

ਲੌਗ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਗੋਪਨੀਯਤਾ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੁੰਦੀ ਹੈ

ਇੱਕ ਵਧੀਆ ਸਥਿਤੀ ਢਾਂਚੇ ਨੂੰ ਵੀ ਲਾਪਰਵਾਹ ਲੌਗਿੰਗ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ।

• EUDI ਭਰੋਸਾ ਕਰਨ ਵਾਲੀਆਂ ਧਿਰਾਂ ਦੀਆਂ ਮਿਸਾਲਾਂ ਨੂੰ ਲੋੜ ਨਾ ਰਹਿਣ ‘ਤੇ ਵਿਲੱਖਣ ਤੱਤ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਤੁਰੰਤ ਰੱਦ ਕਰਨ ਦੀ ਲੋੜ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਦੀ ਮਨਾਹੀ ਕਰਦਾ ਹੈ।
• AAMVA ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ mDL ਧਾਰਕਾਂ ਜਾਂ mDL ਵਰਤੋਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਤੋਂ ਮਨ੍ਹਾ ਕਰਦਾ ਹੈ ਸਿਵਾਏ ਜਿੱਥੇ ਕਾਨੂੰਨ ਦੀ ਲੋੜ ਹੋਵੇ, ਜਾਰੀ ਕਰਨ ਵਾਲੀਆਂ ਅਥਾਰਟੀਆਂ ਨੂੰ ਸਥਿਰ ਜਾਂ ਲੰਮੇ ਸਮੇਂ ਦੇ ਮੈਟਾਡੇਟਾ ਦੀ ਸਾਂਝ ਘੱਟ ਕਰਨ ਦੀ ਲੋੜ ਕਰਦਾ ਹੈ, ਅਤੇ ਗਤੀਵਿਧੀ-ਲੌਗ ਪਹੁੰਚ ਧਾਰਕ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।
• AAMVA ਇਹ ਵੀ ਲੋੜ ਕਰਦਾ ਹੈ ਕਿ ਡਿਵਾਈਸ ‘ਤੇ ਮਿਟਾਉਣਾ ਉਹ ਲੌਗ ਜਾਣਕਾਰੀ ਅਤੇ ਮੈਟਾਡੇਟਾ ਹਟਾਵੇ ਜੋ ਵਰਤੋਂ ਇਤਿਹਾਸ ਦੱਸ ਸਕਦੇ ਹਨ — ਅਤੇ ਇਹ ਮਿਟਾਉਣਾ ਔਫਲਾਈਨ ਵੀ ਸੰਭਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਵਿਵਹਾਰ ਹੈ, ਪ੍ਰਬੰਧਕੀ ਸਫਾਈ ਨਹੀਂ। ਭਵਿੱਖੀ IDP ਨੂੰ ਲੰਮੇ ਸਮੇਂ ਦੇ ਪਛਾਣਕਰਤਾਵਾਂ, ਟਾਈਮਸਟੈਂਪਾਂ, ਅਤੇ ਲੌਗਾਂ ਨੂੰ ਸੰਭਾਵਿਤ ਟ੍ਰੈਕਿੰਗ ਸਾਧਨਾਂ ਵਜੋਂ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਹੋਰ ਸਾਬਿਤ ਨਾ ਹੋਵੇ।

ਭਵਿੱਖੀ IDP ਲਈ ਇੱਕ ਠੋਸ ਕੋਈ-ਕਾਲ-ਹੋਮ ਢਾਂਚਾ

ਸਿਧਾਂਤਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ, ਇਹ ਹੈ ਜੋ ਸਿਸਟਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

1. ਡਿਵਾਈਸ-ਬੱਧ ਅਧਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਰੀ ਕਰੋ। ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਵਾਲਿਟ ਦੇ ਸੁਰੱਖਿਅਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੁੰਜੀਆਂ ਨਾਲ ਬੰਨ੍ਹੋ — EUDI ਦੁਆਰਾ PIDs ਅਤੇ 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 ਸਮੇਤ ਮਿਆਰ ਸੰਸਥਾਵਾਂ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਇਸ ਦੀ ਲੋੜ ਕਰਦੀਆਂ ਹਨ। ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਸੰਪੂਰਨ ਅਸਲ-ਸਮੇਂ ਦੀ ਤਾਜ਼ਗੀ ਸੰਪੂਰਨ ਔਫਲਾਈਨ ਸੰਚਾਲਨ ਨਾਲ ਅਸੰਗਤ ਹੈ, ਇਸ ਲਈ ਤਾਜ਼ਗੀ ਇੱਕ ਨੀਤੀ ਫ਼ੈਸਲਾ ਬਣਨੀ ਚਾਹੀਦੀ ਹੈ, ਕੋਈ ਸਖ਼ਤ ਨਿਰਭਰਤਾ ਨਹੀਂ।