DAT (Distributed Access Token) ​

1. Überblick ​

Mit steigender Anzahl gleichzeitiger Benutzer wächst auch die Anzahl der Sitzungen (Sessions), wodurch der Sitzungsserver übermäßig belastet wird.

DAT ist eine Token-Spezifikation, die entwickelt wurde, um dieses Lastproblem des Sitzungsservers zu lösen und eine effiziente, zustandslose (Stateless) Authentifizierung ohne gemeinsamen Zustand zwischen den Servern zu ermöglichen.

DAT ist eine Zeichenkette aus fünf festen Feldern, die durch Punkte (.) getrennt sind. Die einzelnen Felder lassen sich ohne JSON-Parsing allein anhand der Position der Trennzeichen herausschneiden, und die Ablaufzeit sowie der verschlüsselte Bereich sind bereits Bestandteil der Spezifikation selbst.

2. Wire-Format ​

expire . cid . plain . secure . signature

2.1. Detailspezifikation der einzelnen Felder ​

Ablaufzeit : uint64 (Unix Time)

• Gibt die Ablaufzeit des Tokens als vorzeichenlose 64-Bit-Ganzzahl in Sekunden (Seconds) an.
• Es sind ausschließlich reine Dezimalziffern zulässig. Vorzeichen, Leerzeichen oder Trennzeichen führen zu einem Formatfehler.

CID : Hex (uint64)

• Die Zertifikats-ID (Certificate ID), die zur Verifizierung des Tokens verwendet wird.
• Es sind ausschließlich reine Hexadezimalziffern zulässig; das Präfix 0x wird nicht verwendet.

Klartextdaten : Base64Url (Binary)

• Enthält Daten, die dem Client offengelegt werden. Neben Zeichenketten werden auch Binärdaten unterstützt, die vom Client dekodiert und eingesehen werden können.
• Diese Daten werden nicht verschlüsselt. Sensible Werte dürfen hier nicht abgelegt werden.

Verschlüsselte Daten : Base64Url (Binary)

• Enthält Daten, die vor dem Client verborgen bleiben. Sie sind mit dem Verschlüsselungsalgorithmus des Zertifikats verschlüsselt, sodass ein Client ohne Zertifikat den Inhalt nicht entschlüsseln kann.
• Der innere Aufbau ist IV(96bit) + Chiffrat, wobei der IV bei jeder Verschlüsselung neu erzeugt wird.

Signatur : Base64Url (Binary)

• Signaturdaten zur Überprüfung des Tokens auf Fälschung und Manipulation. Sie werden erzeugt, indem die vorangehenden Felder mit dem Signaturalgorithmus des Zertifikats signiert werden.
• Bei einem Token, dessen Signaturprüfung fehlschlägt, darf keinem einzigen Feld vertraut werden.

3. Kanonische Regeln (Canonical Rules) ​

Damit in verschiedenen Sprachen implementierte Clients dasselbe Token identisch interpretieren, dürfen die folgenden Regeln zwischen den Implementierungen nicht voneinander abweichen. Die Referenzimplementierung ist Rust (dat-rust); alle übrigen Implementierungen richten sich nach diesen Regeln.

3.1. Parsen numerischer Felder ​

expire und cid werden strikt interpretiert. Die folgenden Eingaben werden allesamt als Formatfehler abgelehnt.

3.2. Ablaufprüfung ​

DAT-Token und Zertifikat haben unterschiedliche Ablaufgrenzen. Verwechseln Sie diese nicht.

Ein Token wird in dem Moment ungültig, in dem seine Ablaufzeit erreicht ist; ein Zertifikat bleibt bis zu diesem Zeitpunkt gültig. Das Zertifikat muss einen Tick länger leben als das Token, damit ein an der Grenze ausgestelltes Token noch verifiziert werden kann.

3.3. Leere secure-Nutzlast ​

Sind keine zu verschlüsselnden Daten vorhanden, ist secure eine leere Zeichenkette.

• encrypt(leere Eingabe) → leere Ausgabe (weder IV noch GCM-Tag werden angehängt)
• decrypt(leere Eingabe) → leere Ausgabe
• Ist der Wert nicht leer, aber kürzer oder gleich der IV-Länge (12 Bytes), liegt ein Entschlüsselungsfehler vor.

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ ein gültiges Token, bei dem die secure-Position leer ist

4. Ausstellung und Verifizierung ​

4.1. Ausstellungsablauf ​

1. Aus den Zertifikaten, die der Manager besitzt, wird ein ausstellungsfähiges (issuable) Zertifikat ausgewählt.
2. expire = now + dat_ttl_seconds wird berechnet.
3. plain wird nach Base64Url kodiert; secure wird verschlüsselt und anschließend nach Base64Url kodiert.
4. Die Zeichenkette expire.cid.plain.secure wird signiert und die Signatur als letztes Feld angehängt.

4.2. Verifizierungsablauf ​

1. Die Zeichenkette wird an den Punkten (.) in fünf Felder zerlegt. Weicht die Feldanzahl ab, liegt ein Formatfehler vor.
2. expire wird geprüft. Abgelaufene Tokens werden bereits vor der Signaturprüfung abgelehnt.
3. Über cid wird das Zertifikat gesucht. Ist es nicht vorhanden, ist keine Verifizierung möglich.
4. Die Signatur wird über den Abschnitt expire.cid.plain.secure verifiziert.
5. Erst nach erfolgreicher Verifizierung wird secure entschlüsselt.

5. Vergleich mit JWT ​

DAT und JWT (JSON Web Token) teilen die durch Punkte (.) getrennte Tokenstruktur sowie die Verifizierung mittels Signatur, unterscheiden sich im internen Design jedoch in den folgenden wesentlichen Punkten.

5.1. Vergleich der strukturellen Unterschiede ​

• JWT-Struktur

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

• DAT-Struktur

  Ablaufzeit	CID	Klartextdaten	Verschlüsselte Daten	Signatur
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. Wesentliche Unterschiede ​

• Binärbasierte Kompaktheit: JWT verarbeitet Header und Body als JSON-Zeichenketten, während DAT Binärdaten (Binary) direkt verarbeitet und dadurch die Datengröße optimiert sowie die Parsing-Effizienz erhöht.
• Integrierte Sicherheit (Feld Verschlüsselte Daten): Bei JWT ist der Payload standardmäßig im Klartext sichtbar; soll er verschlüsselt werden, muss eine separate Spezifikation wie JWE angewendet werden. DAT hingegen unterstützt Verschlüsselung nativ über das Feld Verschlüsselte Daten direkt im Token.
• Erzwungene Ablaufzeitbeschränkung: In JWT ist das Feld exp (Claims) optional, während in DAT das Feld Ablaufzeit strukturell verpflichtend ist, sodass die Gültigkeitsprüfung zwingend durchgeführt wird.
• Keine Algorithmusaushandlung: Da JWT den Wert alg im Header im Token selbst mitführt, entsteht eine Angriffsfläche für Algorithmusverwechslungsangriffe. Bei DAT bestimmt das Zertifikat den Algorithmus, und das Token enthält keinerlei Algorithmusinformationen.