ਪੁਲਿਸ, ਕਿਰਾਏ ਦੇ ਕਾਊਂਟਰ, ਮਾਲਕ, ਬੀਮਾਕਰਤਾ: ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਡੇਟਾ ਕਿਉਂ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ

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

ਇੱਕ ਡ੍ਰਾਈਵਰ। ਗੱਡੀ ਚਲਾਉਣ ਦਾ ਇੱਕ ਮੂਲ ਅਧਿਕਾਰ। ਇੱਕ ਵਾਲਿਟ। ਪਰ ਚਾਰ ਬਹੁਤ ਵੱਖਰੇ ਤਸਦੀਕਕਰਤਾ:

• ਸੜਕ ਕਿਨਾਰੇ ਇੱਕ ਪੁਲਿਸ ਅਧਿਕਾਰੀ
• ਗੱਡੀ ਚੁੱਕਣ ਵੇਲੇ ਕਾਰ ਕਿਰਾਏ ਦਾ ਕਾਊਂਟਰ
• ਫਲੀਟ ਯੋਗਤਾ ਜਾਂਚਦਾ ਮਾਲਕ
• ਦਾਅਵੇ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਬੀਮਾਕਰਤਾ

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

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

ਭੌਤਿਕ ਕਾਰਡ ਨੇ ਸਾਨੂੰ ਗਲਤ ਸੋਚਣਾ ਕਿਉਂ ਸਿਖਾਇਆ

ਇੱਕ ਭੌਤਿਕ ਲਾਇਸੈਂਸ ਨੇ ਸਾਨੂੰ ਸਭ-ਕੁਝ-ਦਿਖਾਓ ਪਹੁੰਚ ਵਿੱਚ ਢਾਲਿਆ। ਤੁਸੀਂ ਕਾਰਡ ਦਿੰਦੇ ਹੋ। ਦੂਜਾ ਵਿਅਕਤੀ ਕਾਰਡ ‘ਤੇ ਜੋ ਕੁਝ ਹੈ ਦੇਖਦਾ ਹੈ। ਇਹੀ ਪੂਰਾ ਸੰਪਰਕ ਹੈ।

ਕਾਗਜ਼ੀ ਦੁਨੀਆ ਵਿੱਚ ਇਹ ਪਹੁੰਚ ਸਵੀਕਾਰਯੋਗ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਹੈ। ਡਿਜੀਟਲ ਦੁਨੀਆ ਵਿੱਚ ਇਹ ਅਸਵੀਕਾਰਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ।

W3C VC ਡੇਟਾ ਮਾਡਲ 2.0 ਸਿੱਧਾ ਕਹਿੰਦਾ ਹੈ: ਇੱਕ ਡ੍ਰਾਈਵਿੰਗ ਲਾਇਸੈਂਸ ਵਿੱਚ ID ਨੰਬਰ, ਉਚਾਈ, ਭਾਰ, ਜਨਮ ਤਾਰੀਖ਼, ਅਤੇ ਘਰ ਦਾ ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ — ਪਰ ਇਹ ਫਿਰ ਵੀ ਕਿਸੇ ਖਾਸ ਲੈਣ-ਦੇਣ ਲਈ ਲੋੜ ਤੋਂ ਕਿਤੇ ਵੱਧ ਹੋ ਸਕਦਾ ਹੈ। ਮੌਜੂਦਾ ਮਾਪਦੰਡਾਂ ਤੋਂ ਮੁੱਖ ਨੁਕਤੇ:

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

ਸਹੀ ਮਾਡਲ ਨੀਤੀ-ਆਧਾਰਿਤ ਖੁਲਾਸਾ ਹੈ

ਜੇ ਤੁਸੀਂ ਇੱਕ ਗੰਭੀਰ ਆਰਕੀਟੈਕਚਰ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਹੀ ਮਾਡਲ ਡਿਜੀਟਲ ਕਾਰਡ ਪੇਸ਼ਕਾਰੀ ਨਾਲੋਂ ਗੁਣ-ਆਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਦੇ ਨੇੜੇ ਹੈ।

NIST SP 800-205 ਪਹੁੰਚ-ਨਿਯੰਤਰਣ ਫੈਸਲਿਆਂ ਨੂੰ ਵਿਸ਼ੇ, ਵਸਤੂ, ਬੇਨਤੀ ਕੀਤੀ ਕਾਰਵਾਈ, ਅਤੇ ਵਾਤਾਵਰਣ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨਾਲ ਜੁੜੇ ਗੁਣਾਂ ਦੇ ਨੀਤੀ ਵਿਰੁੱਧ ਮੁਲਾਂਕਣ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਭਵਿੱਖ ਦੇ IDP ਲਈ ਬਿਲਕੁਲ ਸਹੀ ਢਾਂਚਾ ਹੈ:

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

NIST ਇਹ ਵੀ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ਗੁਣ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਦਾਣੇਦਾਰਤਾ, ਸ਼ਾਸਨ, ਅਤੇ ਗੁਣਾਂ ਦੀ ਕਮੀ, ਸਮੂਹਕਰਨ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਕਰਨ ਲਈ ਵਿਧੀਆਂ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਲਈ ਭਵਿੱਖ ਦੇ IDP ਨੂੰ ਇਹ ਨਹੀਂ ਪੁੱਛਣਾ ਚਾਹੀਦਾ: ਕੀ ਇਹ ਤਸਦੀਕਕਰਤਾ ਲਾਇਸੈਂਸ ਪੜ੍ਹ ਸਕਦਾ ਹੈ? ਇਸਨੂੰ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ: ਇਸ ਤਸਦੀਕਕਰਤਾ ਨੂੰ ਕਿਹੜੇ ਦਾਅਵੇ ਮਿਲ ਸਕਦੇ ਹਨ, ਕਿਸ ਉਦੇਸ਼ ਲਈ, ਇਸ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਕਿਹੜੇ ਰੱਖਣ ਦੇ ਨਿਯਮਾਂ ਨਾਲ?

ਤਸਦੀਕਕਰਤਾ ਨੂੰ ਕੁਝ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਪਛਾਣ ਦੱਸਣੀ ਚਾਹੀਦੀ ਹੈ

ਭਵਿੱਖ ਦੇ IDP ਦੀ ਸ਼ੁਰੂਆਤ ਵਾਲਿਟ ਦੁਆਰਾ ਡੇਟਾ ਦਿਖਾਉਣ ਨਾਲ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਇਹ ਤਸਦੀਕਕਰਤਾ ਦੁਆਰਾ ਇਹ ਸਾਬਤ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਹ ਕੌਣ ਹੈ।

EUDI ਆਰਕੀਟੈਕਚਰ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੈ। ਭਰੋਸੇਯੋਗ ਧਿਰਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ ‘ਤੇ:

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

ਫਿਰ ਉਪਭੋਗਤਾ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ ਕੌਣ ਪੁੱਛ ਰਿਹਾ ਹੈ, ਕੀ ਮੰਗਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਕੀ ਬੇਨਤੀ ਰਜਿਸਟਰਡ ਦਾਇਰੇ ਵਿੱਚ ਹੈ।

ETSI ਦਾ ਮੌਜੂਦਾ ਵਾਲਿਟ-ਭਰੋਸੇਯੋਗ-ਧਿਰ ਸਰਟੀਫਿਕੇਟ ਕੰਮ ਇਸਨੂੰ ਹੋਰ ਠੋਸ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਲਿਟ-ਭਰੋਸੇਯੋਗ-ਧਿਰ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਸਰਟੀਫਿਕੇਟ ਭਰੋਸੇਯੋਗ ਧਿਰ ਦੀ ਉਦੇਸ਼ਿਤ ਵਰਤੋਂ ਅਤੇ ਉਹਨਾਂ ਗੁਣਾਂ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੇ ਮੰਗਣ ਲਈ ਰਜਿਸਟਰ ਕੀਤੇ ਹਨ। ਸੰਬੰਧਿਤ ਪਹੁੰਚ ਸਰਟੀਫਿਕੇਟ ਇਹ ਯਕੀਨੀ ਕਰਨ ਲਈ ਮੌਜੂਦ ਹੈ ਕਿ ਬੇਨਤੀ ਇੱਕ ਜਾਇਜ਼, ਅਧਿਕਾਰਤ ਧਿਰ ਤੋਂ ਆਉਂਦੀ ਹੈ। ETSI ਭਰੋਸੇਯੋਗ-ਧਿਰ ਮੈਟਾਡੇਟਾ ਵੀ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜਿਵੇਂ:

• ਵਪਾਰਕ ਨਾਮ
• ਸਹਾਇਤਾ URI
• ਉਦੇਸ਼ਿਤ ਵਰਤੋਂ
• ਅਧਿਕਾਰ
• ਰਜਿਸਟ੍ਰੀ URI
• ਨਿਗਰਾਨ-ਅਥਾਰਿਟੀ ਜਾਣਕਾਰੀ

ਭਵਿੱਖ ਦੇ IDP ਦਾ ਦੂਜਾ ਸਿਧਾਂਤ: ਕੋਈ ਤਸਦੀਕਕਰਤਾ ਪਛਾਣ ਨਹੀਂ, ਕੋਈ ਖੁਲਾਸਾ ਨਹੀਂ।

ਸਹਿਮਤੀ ਸਕ੍ਰੀਨਾਂ ਕਾਫ਼ੀ ਕਿਉਂ ਨਹੀਂ ਹਨ

ਇੱਥੇ ਇੱਕ ਹੋਰ ਗਲਤੀ ਹੈ: ਉਪਭੋਗਤਾ ਦੀ ਮਨਜ਼ੂਰੀ ਨੂੰ ਕਾਨੂੰਨੀ ਜਾਇਜ਼ਤਾ ਦੇ ਸਮਾਨ ਸਮਝਣਾ।

EUDI ਆਰਕੀਟੈਕਚਰ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਕਹਿੰਦਾ ਹੈ ਕਿ ਗੁਣਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਉਪਭੋਗਤਾ ਦੀ ਮਨਜ਼ੂਰੀ ਨੂੰ ਭਰੋਸੇਯੋਗ ਧਿਰ ਦੇ ਨਿੱਜੀ ਡੇਟਾ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਕਾਨੂੰਨੀ ਆਧਾਰ ਵਜੋਂ ਨਹੀਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ। ਭਰੋਸੇਯੋਗ ਧਿਰ ਕੋਲ ਅਜੇ ਵੀ ਆਪਣਾ ਕਾਨੂੰਨੀ ਆਧਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। EUDI ਸਾਰੇ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੀ ਮਨਜ਼ੂਰੀ ਵੀ ਜ਼ਰੂਰੀ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਮਾਮਲੇ ਵੀ ਸ਼ਾਮਲ ਹਨ ਜਿੱਥੇ ਭਰੋਸੇਯੋਗ ਧਿਰ ਕਾਨੂੰਨ ਲਾਗੂ ਕਰਨ ਜਾਂ ਕਿਸੇ ਹੋਰ ਸਰਕਾਰੀ ਏਜੰਸੀ ਦਾ ਹਿੱਸਾ ਹੋ ਸਕਦੀ ਹੈ।

ਇੱਕ ਚੰਗਾ ਵਾਲਿਟ ਇੰਟਰਫੇਸ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇਕੱਲੇ ਤਸਦੀਕਕਰਤਾ ਦੀ ਵਧੀਕੀ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਨਿਯਮ ਇੰਟਰਫੇਸ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਲਈ ਭਵਿੱਖ ਦੇ IDP ਲਈ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ:

• ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤਸਦੀਕਕਰਤਾ ਪ੍ਰਮਾਣਿਕਤਾ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਕੌਣ ਪੁੱਛ ਰਿਹਾ ਹੈ
• ਨੀਤੀ ਪਾਬੰਦੀਆਂ ਇਸ ਬਾਰੇ ਕਿ ਉਹ ਤਸਦੀਕਕਰਤਾ ਸ਼੍ਰੇਣੀ ਕੀ ਮੰਗ ਸਕਦੀ ਹੈ

ਬਿਨਾਂ ਦੋਵਾਂ ਦੇ, “ਉਪਭੋਗਤਾ ਦੀ ਚੋਣ” ਨੀਤੀ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਵਿਅਕਤੀ ਉੱਤੇ ਥੋਪਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਬਣ ਜਾਂਦੀ ਹੈ।

1. ਪੁਲਿਸ: ਪੂਰੇ ਵਿਅਕਤੀ ਦੀ ਨਹੀਂ, ਗੱਡੀ ਚਲਾਉਣ ਦੇ ਅਧਿਕਾਰ ਦੀ ਤਸਦੀਕ ਕਰੋ

ਪੁਲਿਸ ਸੜਕ ਕਿਨਾਰੇ ਦ੍ਰਿਸ਼ ਸਭ ਤੋਂ ਕੇਂਦ੍ਰਿਤ ਹੈ।

EU mDL ਮੈਨੂਅਲ ਇਸਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਦੱਸਦਾ ਹੈ: ਪੁਲਿਸ ਜਾਂ ਹੋਰ ਅਧਿਕਾਰੀ ਲੋੜ ਪੈਣ ‘ਤੇ ਲਾਇਸੈਂਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਲਾਇਸੈਂਸ ਦੀ ਵੈਧਤਾ ਅਤੇ ਵਾਹਨ ਅਧਿਕਾਰ ਸ਼ਾਮਲ ਹਨ। ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਵਿੱਚ, ਅਧਿਕਾਰੀ QR-ਟ੍ਰਿਗਰਡ ਪ੍ਰਵਾਹ, Bluetooth, Wi-Fi Aware, ਜਾਂ NFC ਰਾਹੀਂ ਲਾਇਸੈਂਸ ਦੀ ਤਸਦੀਕ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਕੇਂਦ੍ਰਿਤ ਤਸਦੀਕ ਕੰਮ ਹੈ:

• ਕੀ ਇਹ ਵਿਅਕਤੀ ਧਾਰਕ ਹੈ?
• ਕੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵੈਧ ਹੈ?
• ਕਿਹੜੇ ਵਾਹਨ ਅਧਿਕਾਰ ਅਤੇ ਪਾਬੰਦੀਆਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ?

ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ ਆਗਿਆਤਮਕ:

• ਨਾਮ
• ਤਸਵੀਰ
• ਲਾਇਸੈਂਸ ਦੀ ਸਥਿਤੀ
• ਜਾਰੀ ਕਰਨ ਅਤੇ ਮਿਆਦ ਸਮਾਪਤੀ ਦੀਆਂ ਤਾਰੀਖ਼ਾਂ
• ਸ਼੍ਰੇਣੀਆਂ
• ਡ੍ਰਾਈਵਿੰਗ-ਸੰਬੰਧੀ ਪਾਬੰਦੀਆਂ
• ਜਾਰੀਕਰਤਾ ਅਤੇ ਅਧਿਕਾਰ ਖੇਤਰ
• ਤਾਜ਼ਗੀ/ਸਥਿਤੀ ਨਤੀਜਾ

ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ ਆਗਿਆ ਨਹੀਂ:

• ਘਰ ਦਾ ਪਤਾ
• ਅੰਦਰੂਨੀ ਪਛਾਣਕਰਤਾ ਜੋ ਸੜਕ ਕਿਨਾਰੇ ਵਰਤੋਂ ਲਈ ਲੋੜੀਂਦੇ ਨਹੀਂ ਹਨ
• ਹੋਰ ਪ੍ਰਮਾਣਾਂ ਤੋਂ ਅਸੰਬੰਧਿਤ ਗੁਣ
• ਇਤਿਹਾਸਕ ਪੇਸ਼ਕਾਰੀ ਲੌਗ
• ਵਪਾਰਕ ਮੈਟਾਡੇਟਾ

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

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

2. ਕਿਰਾਏ ਦੇ ਕਾਊਂਟਰ: ਯੋਗਤਾ, ਪਛਾਣ ਮੇਲ, ਅਤੇ ਕੁਝ ਵੀ ਅਣਲੋੜੀਂਦਾ ਨਹੀਂ

ਕਿਰਾਏ ਦਾ ਮਾਮਲਾ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਵਿੱਚ ਦੋ ਪਲ ਹਨ: ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਰ-ਸੰਚਾਰ ਪੂਰਵ-ਜਾਂਚ, ਅਤੇ ਚੁੱਕਣ ਵੇਲੇ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਜਾਂ ਕਿਓਸਕ ਚਾਬੀਆਂ ਦਿੰਦਾ ਹੈ।

EU mDL ਮੈਨੂਅਲ ਪਹਿਲਾਂ ਹੀ ਦੋਵਾਂ ਦਾ ਮਾਡਲ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਕਾਰ-ਕਿਰਾਏ ਸੇਵਾ ਬੁਕਿੰਗ ਦੌਰਾਨ ਪਛਾਣ ਦੇ ਸਬੂਤ ਦੇ ਨਾਲ mDL ਮੰਗ ਸਕਦੀ ਹੈ, ਪ੍ਰਮਾਣਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਾਹਨ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੁੱਕਣ ਵੇਲੇ ਗਾਹਕ ਦੀ ਵਿਅਕਤੀਗਤ ਤਸਦੀਕ ਕਰ ਸਕਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਆਪਣੇ mDLs ਕਾਰ-ਕਿਰਾਏ ਕੰਪਨੀਆਂ ਨਾਲ ਵਿਅਕਤੀਗਤ ਤੌਰ ‘ਤੇ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਦੂਰ-ਸੰਚਾਰ ਰਾਹੀਂ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹਨ।

ਕਿਰਾਏ ਦੇ ਕਾਊਂਟਰ ਨੂੰ ਮੁੱਖ ਤੌਰ ‘ਤੇ ਕਿਸੇ ਘਟਨਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਕੀ ਮੈਂ ਇਸ ਬੁਕਿੰਗ ਅਤੇ ਨੀਤੀ ਅਧੀਨ ਇਸ ਗਾਹਕ ਨੂੰ ਇਹ ਵਾਹਨ ਕਿਰਾਏ ‘ਤੇ ਦੇ ਸਕਦਾ ਹਾਂ?

ਦੂਰ-ਸੰਚਾਰ ਪੂਰਵ-ਜਾਂਚ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਪਛਾਣ ਸੰਬੰਧ
• ਤਸਵੀਰ ਜਾਂ ਸਮਾਨ ਪਛਾਣ-ਬੰਧਨ ਤੱਤ
• ਸੰਬੰਧਿਤ ਵਾਹਨ ਸ਼੍ਰੇਣੀ
• ਜਾਰੀ ਕਰਨ ਅਤੇ ਮਿਆਦ ਸਮਾਪਤੀ ਦੀਆਂ ਤਾਰੀਖ਼ਾਂ
• ਮੌਜੂਦਾ ਵੈਧਤਾ
• ਸੰਭਵ ਤੌਰ ‘ਤੇ ਉਮਰ ਸੀਮਾ ਜਾਂ ਉਮਰ ਬੈਂਡ

ਚੁੱਕਣ ਵੇਲੇ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

• ਧਾਰਕ ਉਹੀ ਵਿਅਕਤੀ ਹੈ ਜਿਸਨੇ ਪੂਰਵ-ਜਾਂਚ ਪੂਰੀ ਕੀਤੀ
• ਮੌਜੂਦਾ ਵੈਧਤਾ
• ਸੰਬੰਧਿਤ ਅਧਿਕਾਰ

ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ ਲੋੜੀਂਦਾ ਨਹੀਂ:

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

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

3. ਮਾਲਕ: ਇੱਕ ਤਸਦੀਕਕਰਤਾ ਸ਼੍ਰੇਣੀ, ਪੂਰੀ ਪਛਾਣ ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਦਾ ਰਾਹ ਨਹੀਂ

W3C ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਤਸਦੀਕਕਰਤਾ ਉਦਾਹਰਣ ਵਜੋਂ ਮਾਲਕ ਦੇ ਡਿਜੀਟਲ ਸਿਸਟਮ ਦੁਆਰਾ ਯੂਨੀਵਰਸਿਟੀ ਡਿਗਰੀ ਦੀ ਜਾਂਚ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਸਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਮਾਲਕ ਤਸਦੀਕ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪਾਰਿਸਥਿਤਿਕ ਤੰਤਰਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਮਾਨਤਾ ਪ੍ਰਾਪਤ ਪੈਟਰਨ ਹੈ।

ਇੱਕ ਮਾਲਕ ਜਾਂ ਫਲੀਟ ਆਪਰੇਟਰ ਜਾਇਜ਼ ਤੌਰ ‘ਤੇ ਜਾਣਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ:

• ਕੀ ਕਰਮਚਾਰੀ ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਕੁਝ ਵਾਹਨ ਸ਼੍ਰੇਣੀਆਂ ਚਲਾਉਣ ਦਾ ਅਧਿਕਾਰ ਰੱਖਦਾ ਹੈ
• ਕੀ ਮੁੱਖ ਪਾਬੰਦੀਆਂ ਮੌਜੂਦ ਹਨ
• ਕੀ ਅਧਿਕਾਰ ਵੈਧ ਰਹਿੰਦਾ ਹੈ

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

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

ਭਵਿੱਖ ਦਾ IDP ਕੰਮ ਵਾਲੀ ਜਗ੍ਹਾ ਦਾ ਪਹੁੰਚ ਬੈਜ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ।

ਮਾਲਕ ਅਤੇ ਫਲੀਟ ਵਰਤੋਂ ਲਈ, ਸਹੀ ਪੈਟਰਨ ਆਮ ਤੌਰ ‘ਤੇ ਹੈ:

• ਕੰਮ-ਸੰਬੰਧੀ ਅਧਿਕਾਰ ਜਾਂਚ
• ਸ਼ਾਇਦ ਸਮੇਂ-ਸਮੇਂ ਦੀ ਪਾਲਣਾ ਪ੍ਰਮਾਣਿਕਤਾ
• ਸ਼ਾਇਦ ਇੱਕ ਦਾਅਵਾ ਕਿ ਧਾਰਕ ਨਿਰਧਾਰਤ ਸ਼੍ਰੇਣੀਆਂ ਲਈ ਵੈਧ ਰਹਿੰਦਾ ਹੈ
• ਪਰ ਹਰ ਵਾਰ ਜਦੋਂ ਕਰਮਚਾਰੀ ਕਿਸੇ ਸਿਸਟਮ ਵਿੱਚ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ ਜਾਂ ਸ਼ਿਫਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਤਾਂ ਸਾਰੇ ਲਾਇਸੈਂਸ ਡੇਟਾ ਦਾ ਡਿਫੌਲਟ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ

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

4. ਬੀਮਾਕਰਤਾ: ਦਾਅਵੇ ਨਿਰੰਤਰ ਦ੍ਰਿਸ਼ਟਤਾ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹਨ

ਬੀਮੇ ਦਾ ਮਾਮਲਾ ਅਕਸਰ ਅਸਲ ਹੁੰਦਾ ਹੈ। EU mDL ਵਰਤੋਂ-ਮਾਮਲੇ ਸਮੱਗਰੀ ਵਿੱਚ, ਬੀਮਾਕਰਤਾ ਅਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਕਿਰਾਏ ਦੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਪ੍ਰਗਟ ਹੁੰਦੇ ਹਨ: ਬੀਮਾ ਕੰਪਨੀਆਂ ਕਾਰ-ਕਿਰਾਏ ਕੰਪਨੀਆਂ ਨੂੰ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕੀ ਕਾਰ ਕਿਰਾਏ ‘ਤੇ ਲੈਣ ਵਾਲੇ ਵਿਅਕਤੀ ਨੂੰ ਗੱਡੀ ਚਲਾਉਣ ਦਾ ਅਧਿਕਾਰ ਹੈ। ਬੀਮਾ ਪਹਿਲਾਂ ਹੀ ਡ੍ਰਾਈਵਿੰਗ-ਤਸਦੀਕ ਪ੍ਰਵਾਹ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਬੀਮਾਕਰਤਾ ਨੂੰ ਪੁਲਿਸ ਵਾਂਗੂ ਉਹੀ ਡੇਟਾ, ਜਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਤੱਕ ਸਥਾਈ ਪਹੁੰਚ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ।

ਭਵਿੱਖ ਦੇ IDP ਨੂੰ ਬੀਮਾਕਰਤਾਵਾਂ ਨੂੰ ਵੱਖਰੀ ਉਦੇਸ਼ਿਤ ਵਰਤੋਂ ਨਾਲ ਵੱਖਰੀ ਤਸਦੀਕਕਰਤਾ ਸ਼੍ਰੇਣੀ ਵਜੋਂ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਅੰਡਰਰਾਈਟਿੰਗ
• ਕਿਰਾਏ-ਜੋਖਮ ਤਸਦੀਕ
• ਨੁਕਸਾਨ-ਪਿੱਛੋਂ ਦਾਅਵੇ ਦੀ ਸੰਭਾਲ
• ਧੋਖਾਧੜੀ ਸਮੀਖਿਆ

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

ਜਾਇਜ਼, ਘਟਨਾ-ਵਿਸ਼ੇਸ਼ ਉਦਾਹਰਣਾਂ:

• ਸਬੂਤ ਕਿ ਸੰਬੰਧਿਤ ਪਲ ‘ਤੇ ਲਾਇਸੈਂਸ ਵੈਧ ਸੀ
• ਸੰਬੰਧਿਤ ਵਾਹਨ ਅਧਿਕਾਰ ਦਾ ਸਬੂਤ
• ਪਛਾਣ ਸੰਬੰਧ ਦਾ ਸਬੂਤ ਜਿੱਥੇ ਦਾਅਵੇ ਲਈ ਜ਼ਰੂਰੀ ਹੈ
• ਦਾਅਵਾ-ਵਿਸ਼ੇਸ਼ ਖੁਲਾਸਾ

ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ ਆਗਿਆ ਨਹੀਂ:

• ਅੰਡਰਲਾਈੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਤੱਕ ਸਥਾਈ ਪਹੁੰਚ
• ਹਰ ਵਾਰ ਜਦੋਂ ਗਾਹਕ ਬੀਮਾਕਰਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦਾ ਹੈ ਤਾਂ ਵਾਰ-ਵਾਰ ਆਮ ਤਸਦੀਕ
• ਡ੍ਰਾਈਵਿੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਲੌਗਇਨ ਟੋਕਨ ਵਜੋਂ ਵਰਤੋਂ
• ਅਸੰਬੰਧਿਤ ਗੁਣਾਂ ਦਾ ਸੰਗ੍ਰਹਿ

ਡ੍ਰਾਈਵਿੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਿਗਰਾਨੀ ਗਾਹਕੀ ਨਹੀਂ ਹੈ। ਅਤੇ ਇਸਨੂੰ ਚੁੱਪਚਾਪ ਅਜਿਹਾ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ।

ਵਿਚੋਲੇ ਦਿਖਾਈ ਦੇਣੇ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹਨ

ਅਸਲ ਬਾਜ਼ਾਰਾਂ ਵਿੱਚ ਵਿਚੋਲੇ ਸ਼ਾਮਲ ਹਨ। ਕਿਰਾਏ ਦੇ ਪਲੇਟਫਾਰਮ, ਫਲੀਟ ਵਿਕਰੇਤਾ, ਮਾਲਕ HR ਸਿਸਟਮ, ਅਤੇ ਬੀਮਾ ਦਾਅਵਾ ਪ੍ਰੋਸੈਸਰ ਅਕਸਰ ਤੀਜੀਆਂ ਧਿਰਾਂ ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ ਹਨ।

EUDI ਆਰਕੀਟੈਕਚਰ ਇਸਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ:

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

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

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

ਧਾਰਨ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਦਾ ਹਿੱਸਾ ਹੈ

ਚੋਣਵੇਂ ਖੁਲਾਸੇ ਬਾਰੇ ਜ਼ਿਆਦਾਤਰ ਚਰਚਾਵਾਂ ਬਹੁਤ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਇਸ ਗੱਲ ‘ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕੀ ਖੁਲਾਸਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਹ ਇਸ ਗੱਲ ‘ਤੇ ਕਾਫ਼ੀ ਧਿਆਨ ਨਹੀਂ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀਆਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਇਹ ਕਿੰਨੇ ਸਮੇਂ ਤੱਕ ਰਹਿੰਦਾ ਹੈ।

ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਇਕਜੁੱਟ ਹੋ ਰਿਹਾ ਹੈ:

• AAMVA: ਵਾਲਿਟ ਨੂੰ ਧਾਰਕ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਡੇਟਾ ਮੰਗਿਆ ਗਿਆ ਸੀ ਅਤੇ ਕੀ ਤਸਦੀਕਕਰਤਾ ਇਸਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਹੈ; ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ ਕਾਨੂੰਨ ਦੁਆਰਾ ਲੋੜੇ ਜਾਣ ਨੂੰ ਛੱਡ ਕੇ ਧਾਰਕਾਂ ਜਾਂ mDL ਵਰਤੋਂ ਨੂੰ ਟਰੈਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ
• W3C: ਧਾਰਕ ਸਾਫਟਵੇਅਰ ਨੂੰ ਤਸਦੀਕਕਰਤਾਵਾਂ ਨਾਲ ਸਾਂਝੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਦੇ ਲੌਗ ਪ੍ਰਦਾਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਕਿ ਵਾਧੂ ਬੇਨਤੀਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਜਾ ਸਕੇ
• EUDI: ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲੈਣ-ਦੇਣ ਲੌਗ ਤੱਕ ਪਹੁੰਚ ਕਰਨ, ਸ਼ੱਕੀ ਬੇਨਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨ, ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਮੰਗ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਧਾਰਨ ਸ਼੍ਰੇਣੀ ਖੁਲਾਸਾ ਨੀਤੀ ਦਾ ਹੀ ਹਿੱਸਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

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

ਇੱਕ ਭਵਿੱਖ ਦਾ IDP ਜੋ ਧਾਰਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ ਕੇਵਲ ਅੰਸ਼ਿਕ ਤੌਰ ‘ਤੇ ਗੋਪਨੀਯਤਾ-ਸੁਰੱਖਿਅਤ ਕਰਨ ਵਾਲਾ ਹੈ।

ਵਾਲਿਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਜੇ ਮੈਨੂੰ ਇਸ ਪੂਰੇ ਲੇਖ ਨੂੰ ਇੱਕ ਲਾਗੂਕਰਨ ਨਿਯਮ ਤੱਕ ਘਟਾਉਣਾ ਹੋਵੇ, ਤਾਂ ਇਹ ਹੋਵੇਗਾ:

ਵਾਲਿਟ ਨੂੰ “ਕੀ ਮੈਂ ਇਹ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹਾਂ?” ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ “ਕੀ ਮੈਂ ਇਸ ਪ੍ਰਮਾਣਿਤ ਤਸਦੀਕਕਰਤਾ ਨੂੰ, ਇਸ ਉਦੇਸ਼ਿਤ ਵਰਤੋਂ ਲਈ, ਇਸ ਸੰਦਰਭ ਵਿੱਚ, ਇਸ ਧਾਰਨ ਸ਼੍ਰੇਣੀ ਅਧੀਨ, ਦਾਅਵਿਆਂ ਦਾ ਇਹ ਸਮੂਹ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹਾਂ?”

ਉਹ ਫੈਸਲਾ ਘੱਟੋ ਘੱਟ ਇਹਨਾਂ ਇਨਪੁੱਟਾਂ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਤਸਦੀਕਕਰਤਾ ਦੀ ਪਛਾਣ
• ਤਸਦੀਕਕਰਤਾ ਸ਼੍ਰੇਣੀ
• ਉਦੇਸ਼ਿਤ ਵਰਤੋਂ
• ਰਜਿਸਟਰਡ ਗੁਣ ਦਾਇਰਾ
• ਜਾਰੀਕਰਤਾ ਤੋਂ ਖੁਲਾਸਾ ਨੀਤੀ, ਜੇ ਮੌਜੂਦ ਹੈ
• ਵਾਤਾਵਰਣ (ਸੜਕ ਕਿਨਾਰੇ, ਚੁੱਕਣਾ, ਦੂਰ-ਸੰਚਾਰ, ਫਲੀਟ, ਦਾਅਵਾ)
• ਧਾਰਕ ਦੀ ਮਨਜ਼ੂਰੀ
• ਲਾਗੂ ਧਾਰਨ ਨੀਤੀ

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

ਮੁੱਖ ਦਲੀਲ

ਭਵਿੱਖ ਦੇ IDP ਨੂੰ ਇਹ ਨਹੀਂ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਕਿ ਕੀ ਡੇਟਾ ਖੁਲਾਸਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਕੌਣ ਪੁੱਛ ਰਿਹਾ ਹੈ?
• ਕਿਸ ਉਦੇਸ਼ ਲਈ?
• ਕਿਹੜੇ ਅਧਿਕਾਰ ਅਧੀਨ?
• ਕਿਹੜੇ ਸੰਦਰਭ ਵਿੱਚ?
• ਕਿਹੜੇ ਧਾਰਨ ਦੇ ਨਤੀਜਿਆਂ ਨਾਲ?

ਪੁਲਿਸ, ਕਿਰਾਏ ਦੇ ਕਾਊਂਟਰ, ਮਾਲਕ, ਅਤੇ ਬੀਮਾਕਰਤਾ ਬੇਨਤੀ ਦੇ ਦੂਜੇ ਸਿਰੇ ‘ਤੇ ਚਾਰ ਲੋਗੋ ਨਹੀਂ ਹਨ। ਇਹ ਚਾਰ ਵੱਖਰੇ ਜੋਖਮ ਮਾਡਲ, ਚਾਰ ਵੱਖਰੇ ਕਾਨੂੰਨੀ ਸੰਦਰਭ, ਪੁੱਛਣ ਦੇ ਚਾਰ ਵੱਖਰੇ ਕਾਰਨ ਹਨ — ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚਾਰ ਵੱਖਰੇ ਖੁਲਾਸਾ ਸਮੂਹ ਪੈਦਾ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।

ਇਹ ਅਣਲੋੜੀਂਦੀ ਜਟਿਲਤਾ ਨਹੀਂ ਹੈ। ਇਹੀ ਉਹ ਹੈ ਜੋ ਇੱਕ ਆਧੁਨਿਕ ਡ੍ਰਾਈਵਿੰਗ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਉਦੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਹਰ ਤਸਦੀਕਕਰਤਾ ਨੂੰ ਇੱਕੋ ਤਸਦੀਕਕਰਤਾ ਸਮਝਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।