DAT ​

DAT बिंदुओं (.) से अलग की गई ASCII string है। हर फ़ील्ड निश्चित क्रम में ठीक एक बार आता है और हस्ताक्षर पुष्टि करता है कि पहले के फ़ील्ड ठीक उसी रूप में भेजे गए थे।

expire.cid.plain.secure.signature

फ़ील्ड ​

plain हस्ताक्षर के अंतर्गत आता है, इसलिए बदला नहीं जा सकता, पर कोई भी उसे decode कर सकता है। गोपनीय डेटा, व्यक्तिगत डेटा और authorization निर्णयों में सीधे प्रयुक्त मान secure में रखें। खाली secure फ़ील्ड मान्य है।

Canonical निरूपण ​

• पूरा DAT ASCII होना चाहिए।
• संख्याएँ sign, space, prefix या अनावश्यक शुरुआती zero के बिना लिखी जाती हैं। केवल zero का मान 0 लिखा जाता है।
• Base64Url URL-safe alphabet उपयोग करता है और = padding या whitespace स्वीकार नहीं करता।
• समान bytes को कई तरीकों से दिखाने वाली non-canonical Base64Url strings अस्वीकार की जाती हैं।
• अलग फ़ील्ड संख्या या क्रम वाली string DAT नहीं है।

ये नियम अलग-अलग implementations को अलग strings को एक ही DAT मानने से रोकते हैं।

जारी करना ​

1. वर्तमान में जारी करने योग्य प्रमाणपत्र चुनें।
2. वर्तमान समय में प्रमाणपत्र का TTL जोड़कर expire बनाएँ।
3. plain को Base64Url से encode करें।
4. प्रमाणपत्र के encryption algorithm से secure को encrypt करें।
5. पहले के फ़ील्ड बिंदुओं से जोड़ें और उनके ASCII bytes पर हस्ताक्षर करें।

जारी करना केवल प्रमाणपत्र की issuance window में अनुमत है: start <= now <= start + duration।

सत्यापन ​

1. canonical नियमों के अनुसार DAT parse करें।
2. जाँचें कि expire > now। expire == now वाला DAT समाप्त है।
3. cid से मेल खाने वाला प्रमाणपत्र खोजें और पुष्टि करें कि वह सत्यापन के लिए अभी मान्य है।
4. मूल expire.cid.plain.secure bytes पर हस्ताक्षर सत्यापित करें।
5. secure को authenticate और decrypt करें, फिर उसे plain के साथ लौटाएँ।

हस्ताक्षर सत्यापित न करने वाला parsing API केवल निरीक्षण या diagnostics के लिए है। उसके output को authentication या authorization में कभी उपयोग न करें।

विनिर्देश से बाहर की जिम्मेदारियाँ ​

DAT user store, login method, authorization model, token transport header या revocation list निर्धारित नहीं करता। एप्लिकेशन तय करता है कि कौन-से अनुरोध सत्यापित payload उपयोग कर सकते हैं।