DAT (Distributed Access Token) ​

1. Ikhtisar ​

Seiring bertambahnya jumlah pengguna yang terhubung secara bersamaan, jumlah sesi (Session) ikut bertambah sehingga menimbulkan beban berlebih pada server sesi.

DAT adalah spesifikasi token yang dirancang untuk mengatasi masalah beban server sesi tersebut sekaligus mewujudkan autentikasi efisien yang tidak berbagi status antar-server (Stateless).

DAT adalah sebuah string yang terdiri atas 5 bidang tetap yang dipisahkan oleh titik (.). Setiap bidang dapat dipotong hanya berdasarkan posisi pemisahnya tanpa parsing JSON, dan waktu kedaluwarsa serta wilayah terenkripsi sudah termasuk di dalam spesifikasinya sendiri.

2. Format Wire ​

expire . cid . plain . secure . signature

2.1. Spesifikasi Detail Per Bidang ​

Waktu Kedaluwarsa : uint64 (Unix Time)

• Menyatakan waktu kedaluwarsa token sebagai bilangan bulat tak bertanda 64-bit dalam satuan detik (Seconds).
• Hanya angka desimal murni yang diizinkan. Bila mengandung tanda, spasi, atau pemisah, maka dianggap galat format.

CID : Hex (uint64)

• ID sertifikat (Certificate ID) yang digunakan untuk memverifikasi token.
• Hanya angka heksadesimal murni yang diizinkan, dan awalan 0x tidak digunakan.

Data Teks Biasa : Base64Url (Binary)

• Menyimpan data yang dipublikasikan kepada klien. Mendukung bukan hanya string, tetapi juga data biner, dan dapat diperiksa dengan mendekodenya di sisi klien.
• Tidak dienkripsi. Nilai sensitif tidak boleh dimasukkan ke sini.

Data Terenkripsi : Base64Url (Binary)

• Menyimpan data yang dirahasiakan dari klien. Data ini dienkripsi dengan algoritma enkripsi milik sertifikat, sehingga klien yang tidak memiliki sertifikat tidak dapat mendekripsi isinya.
• Struktur internalnya adalah IV(96bit) + ciphertext, dan IV dibangkitkan ulang pada setiap proses enkripsi.

Tanda Tangan : Base64Url (Binary)

• Data tanda tangan untuk memverifikasi pemalsuan atau perubahan token. Dibuat dengan menandatangani bidang-bidang sebelumnya menggunakan algoritma tanda tangan milik sertifikat.
• Token yang gagal verifikasi tanda tangan tidak boleh dipercaya pada bidang mana pun.

3. Aturan Kanonik (Canonical Rules) ​

Agar klien yang diimplementasikan dalam berbagai bahasa menafsirkan token yang sama secara identik, aturan berikut tidak boleh berbeda antar implementasi. Implementasi acuannya adalah Rust (dat-rust), dan seluruh implementasi lain disesuaikan dengan aturan ini.

3.1. Parsing Bidang Numerik ​

expire dan cid ditafsirkan secara ketat. Seluruh masukan berikut ditolak sebagai galat format.

3.2. Penentuan Kedaluwarsa ​

Batas kedaluwarsa token DAT dan sertifikat berbeda satu sama lain. Jangan sampai tertukar.

Token langsung tidak berlaku pada saat waktu kedaluwarsanya tiba, sedangkan sertifikat tetap valid sampai saat tersebut. Sertifikat harus hidup satu tik lebih lama daripada token agar token yang diterbitkan tepat di batas masih dapat diverifikasi.

3.3. Payload secure Kosong ​

Bila tidak ada data yang perlu dienkripsi, secure berupa string kosong.

• encrypt(masukan kosong) → keluaran kosong (tidak ada IV maupun tag GCM yang dilekatkan)
• decrypt(masukan kosong) → keluaran kosong
• Bila tidak kosong namun panjangnya kurang dari atau sama dengan panjang IV (12 byte), maka terjadi galat dekripsi.

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ token normal dengan posisi secure yang kosong

4. Penerbitan dan Verifikasi ​

4.1. Prosedur Penerbitan ​

1. Manajer memilih sertifikat yang dapat menerbitkan (issuable) di antara sertifikat yang dimilikinya.
2. Menghitung expire = now + dat_ttl_seconds.
3. Meng-encode plain ke Base64Url, sedangkan secure dienkripsi terlebih dahulu lalu di-encode ke Base64Url.
4. Menandatangani string expire.cid.plain.secure dan melekatkannya sebagai bidang terakhir.

4.2. Prosedur Verifikasi ​

1. Membagi menjadi 5 bidang berdasarkan titik (.). Bila jumlah bidangnya berbeda, maka galat format.
2. Memeriksa expire. Token yang telah kedaluwarsa ditolak sebelum verifikasi tanda tangan.
3. Mencari sertifikat berdasarkan cid. Bila tidak ada, verifikasi tidak dapat dilakukan.
4. Memverifikasi tanda tangan atas segmen expire.cid.plain.secure.
5. Baru setelah verifikasi berhasil, secure didekripsi.

5. Perbandingan dengan JWT ​

DAT dan JWT (JSON Web Token) berbagi struktur token yang dipisahkan oleh titik (.) serta metode verifikasi melalui tanda tangan, namun terdapat perbedaan mendasar berikut dalam desain internalnya.

5.1. Perbandingan Perbedaan Struktural ​

• Struktur JWT

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

• Struktur DAT

  Waktu Kedaluwarsa	CID	Data Teks Biasa	Data Terenkripsi	Tanda Tangan
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. Perbedaan Utama ​

• Optimasi ringan berbasis Binary: JWT menangani Header dan Body dalam bentuk string JSON, sedangkan DAT menangani data biner (Binary) secara langsung sehingga mengoptimalkan ukuran data dan meningkatkan efisiensi parsing.
• Keamanan bawaan (bidang Data Terenkripsi): JWT pada dasarnya mengekspos payload dalam teks biasa, sehingga bila enkripsi diperlukan harus diterapkan spesifikasi terpisah seperti JWE. Sebaliknya, DAT mendukung fungsi enkripsi pada token itu sendiri melalui bidang Data Terenkripsi.
• Pemaksaan batasan waktu kedaluwarsa: Pada JWT bidang exp (Claims) bersifat opsional, sedangkan pada DAT bidang Waktu Kedaluwarsa diwajibkan dalam struktur token sehingga verifikasi masa berlaku selalu dilakukan.
• Tanpa negosiasi algoritma: JWT membawa sendiri nilai alg pada headernya sehingga muncul permukaan serangan algorithm confusion. Pada DAT, algoritma ditentukan oleh sertifikat dan token sama sekali tidak memuat informasi algoritma.