DAT (Distributed Access Token) ​

1. अवलोकन ​

एक साथ जुड़े उपयोगकर्ताओं की संख्या बढ़ने के साथ सत्रों (Session) की संख्या भी बढ़ती है और सत्र सर्वर पर अत्यधिक भार पड़ने लगता है।

DAT एक ऐसा टोकन विनिर्देश है जिसे सत्र सर्वर के इसी भार की समस्या को हल करने और सर्वरों के बीच स्थिति साझा न करने वाले (Stateless) कुशल प्रमाणीकरण को लागू करने के लिए तैयार किया गया है।

DAT बिंदु (.) से विभाजित 5 निश्चित फ़ील्ड्स से बनी एक स्ट्रिंग है। JSON पार्सिंग के बिना केवल विभाजक की स्थिति से प्रत्येक फ़ील्ड को काटा जा सकता है, और समाप्ति समय तथा एन्क्रिप्टेड क्षेत्र विनिर्देश में ही शामिल हैं।

2. वायर फ़ॉर्मैट ​

expire . cid . plain . secure . signature

2.1. फ़ील्ड-वार विस्तृत विनिर्देश ​

समाप्ति समय : uint64 (Unix Time)

• टोकन की समाप्ति के समय को सेकंड (Seconds) इकाई में 64-बिट अहस्ताक्षरित पूर्णांक के रूप में दर्शाता है।
• केवल शुद्ध दशमलव अंक ही स्वीकार्य हैं। चिह्न, रिक्त स्थान या विभाजक शामिल होने पर यह फ़ॉर्मैट त्रुटि है।

CID : Hex (uint64)

• टोकन सत्यापन में उपयोग होने वाली प्रमाणपत्र ID (Certificate ID) है।
• केवल शुद्ध हेक्साडेसिमल अंक ही स्वीकार्य हैं, और 0x उपसर्ग का उपयोग नहीं किया जाता।

सादा डेटा : Base64Url (Binary)

• क्लाइंट के सामने सार्वजनिक किया जाने वाला डेटा रखता है। यह केवल स्ट्रिंग ही नहीं बल्कि बाइनरी डेटा का भी समर्थन करता है, और क्लाइंट इसे डिकोड करके देख सकता है।
• यह एन्क्रिप्ट नहीं होता। इसमें संवेदनशील मान नहीं डालने चाहिए।

एन्क्रिप्टेड डेटा : Base64Url (Binary)

• क्लाइंट से गोपनीय रखा जाने वाला डेटा रखता है। यह प्रमाणपत्र के एन्क्रिप्शन एल्गोरिदम से एन्क्रिप्ट होता है, इसलिए प्रमाणपत्र न रखने वाला क्लाइंट इसकी सामग्री डिक्रिप्ट नहीं कर सकता।
• आंतरिक संरचना IV(96bit) + सिफरटेक्स्ट है, और IV हर एन्क्रिप्शन पर नए सिरे से बनाया जाता है।

हस्ताक्षर : Base64Url (Binary)

• टोकन की जालसाज़ी व छेड़छाड़ को सत्यापित करने के लिए हस्ताक्षर डेटा है। पिछले फ़ील्ड्स को प्रमाणपत्र के हस्ताक्षर एल्गोरिदम से हस्ताक्षरित करके बनाया जाता है।
• जिस टोकन का हस्ताक्षर सत्यापन विफल हो जाए, उसके किसी भी फ़ील्ड पर भरोसा नहीं करना चाहिए।

3. कैनोनिकल नियम (Canonical Rules) ​

कई भाषाओं में लिखे गए क्लाइंट एक ही टोकन की व्याख्या एक जैसी करें, इसके लिए नीचे दिए नियम किसी भी कार्यान्वयन में अलग नहीं होने चाहिए। संदर्भ कार्यान्वयन Rust (dat-rust) है, और शेष सभी कार्यान्वयन इसी नियम के अनुसार बनाए गए हैं।

3.1. संख्यात्मक फ़ील्ड की पार्सिंग ​

expire और cid की व्याख्या कठोरता से की जाती है। नीचे दिए सभी इनपुट फ़ॉर्मैट त्रुटि मानकर अस्वीकार किए जाते हैं।

3.2. समाप्ति का निर्धारण ​

DAT टोकन और प्रमाणपत्र की समाप्ति की सीमाएँ आपस में भिन्न हैं। इन्हें आपस में न मिलाएँ।

टोकन समाप्ति के समय पर पहुँचते ही तत्काल अमान्य हो जाता है, जबकि प्रमाणपत्र उस क्षण तक वैध रहता है। ऐसा इसलिए है कि प्रमाणपत्र को टोकन से एक टिक अधिक जीवित रहना चाहिए ताकि सीमा पर जारी हुए टोकन का सत्यापन हो सके।

3.3. खाली secure पेलोड ​

यदि एन्क्रिप्ट करने के लिए कोई डेटा न हो, तो secure खाली स्ट्रिंग होती है।

• encrypt(खाली इनपुट) → खाली आउटपुट (न IV जुड़ता है, न GCM टैग)
• decrypt(खाली इनपुट) → खाली आउटपुट
• यदि खाली न हो पर IV की लंबाई (12 बाइट) से कम या बराबर हो, तो यह डिक्रिप्शन त्रुटि है।

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ secure की जगह खाली है — यह एक सामान्य टोकन है

4. जारी करना और सत्यापन ​

4.1. जारी करने की प्रक्रिया ​

1. मैनेजर के पास मौजूद प्रमाणपत्रों में से जारी करने योग्य (issuable) प्रमाणपत्र चुना जाता है।
2. expire = now + dat_ttl_seconds की गणना की जाती है।
3. plain को Base64Url में एन्कोड किया जाता है, और secure को एन्क्रिप्ट करने के बाद Base64Url में एन्कोड किया जाता है।
4. expire.cid.plain.secure स्ट्रिंग पर हस्ताक्षर करके उसे अंतिम फ़ील्ड के रूप में जोड़ा जाता है।

4.2. सत्यापन की प्रक्रिया ​

1. बिंदु (.) से 5 फ़ील्ड्स में विभाजित किया जाता है। फ़ील्ड्स की संख्या भिन्न होने पर यह फ़ॉर्मैट त्रुटि है।
2. expire की जाँच की जाती है। समाप्त हो चुका टोकन हस्ताक्षर सत्यापन से पहले ही अस्वीकार कर दिया जाता है।
3. cid से प्रमाणपत्र खोजा जाता है। न मिलने पर सत्यापन संभव नहीं है।
4. expire.cid.plain.secure खंड पर हस्ताक्षर सत्यापित किया जाता है।
5. सत्यापन सफल होने के बाद ही secure को डिक्रिप्ट किया जाता है।

5. JWT के साथ तुलना ​

DAT और JWT (JSON Web Token) बिंदु (.) से विभाजित टोकन संरचना और हस्ताक्षर के माध्यम से सत्यापन की पद्धति साझा करते हैं, लेकिन आंतरिक डिज़ाइन में उनमें निम्नलिखित प्रमुख अंतर हैं।

5.1. संरचनात्मक अंतर की तुलना ​

• JWT संरचना

  header	body	signature
  Base64Url (JSON String)	Base64Url (JSON String)	Base64Url (Binary)

• DAT संरचना

  समाप्ति समय	CID	सादा डेटा	एन्क्रिप्टेड डेटा	हस्ताक्षर
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. प्रमुख अंतर ​

• Binary आधारित लघुकरण: JWT, Header और Body को JSON स्ट्रिंग के रूप में संभालता है, जबकि DAT बाइनरी (Binary) डेटा को सीधे संभालकर डेटा का आकार अनुकूलित करता है और पार्सिंग दक्षता बढ़ाता है।
• सुरक्षा का अंतर्निहित होना (एन्क्रिप्टेड डेटा फ़ील्ड): JWT में पेलोड (Payload) मूल रूप से सादे रूप में उजागर रहता है, इसलिए एन्क्रिप्शन आवश्यक होने पर JWE जैसा अलग विनिर्देश लागू करना पड़ता है। इसके विपरीत DAT एन्क्रिप्टेड डेटा फ़ील्ड के माध्यम से टोकन में ही एन्क्रिप्शन सुविधा का समर्थन करता है।
• समाप्ति समय की बाध्यता: JWT में exp (Claims) फ़ील्ड वैकल्पिक है, जबकि DAT में समाप्ति समय फ़ील्ड टोकन संरचना में अनिवार्य है, इसलिए वैधता अवधि की जाँच अनिवार्य रूप से की जाती है।
• एल्गोरिदम नेगोशिएशन नहीं: JWT हेडर का alg मान टोकन स्वयं अपने साथ लेकर चलता है, इसलिए एल्गोरिदम कन्फ़्यूज़न हमले का सतह-क्षेत्र बनता है। DAT में एल्गोरिदम प्रमाणपत्र तय करता है और टोकन में एल्गोरिदम की जानकारी होती ही नहीं।