Zrušení podle Status List vysvětleno

Ověřovatel, který právě obdržel průkaz, potřebuje vědět, zda za ním vydavatel stále stojí. Token Status List na to odpovídá, aniž by ověřovatel kontaktoval vydavatele ohledně konkrétního průkazu: status claim uvnitř průkazu odkazuje na kompaktní seznam a jediný bit v tomto seznamu nese odpověď.

Status claim uvnitř průkazu

Vydavatel, který podporuje Token Status List, přidává průkazu při vydání status claim. Ten nese dvě věci: idx, index, který tomuto průkazu patří v seznamu, a uri, adresu Status List Tokenu, který jej obsahuje. Na průkazu se nic jiného nemění, claim je pouze odkaz.

Vydavatel

Přiřadí průkazu index a vloží status claim

Claim se přidává jednou, při vydání, a po celou dobu platnosti průkazu se nemění

Status claim (uvnitř průkazu)

{
  "status": {
    "status_list": {
      "idx": 4271,
      "uri": "https://issuer.example/statuslists/employment-2026-q3"
    }
  }
}

Načtení Status List Tokenu

Při předložení ověřovatel načte uri ze status claimu. Odpovědí je podepsaný Status List Token: JWT s hlavičkou typ nastavenou na statuslist+jwt (nebo ekvivalentní CWT), poskytovaný jako application/statuslist+jwt. Jeho payload nese komprimovaný bitový řetězec a obvykle i ttl, které ověřovateli říká, jak dlouho smí výsledek uchovávat v mezipaměti, než jej musí načíst znovu.

Ověřovatel

Načte idx a uri ze status claimu v právě předloženém průkazu

GET uri

Načte Status List Token a uloží jej do mezipaměti až na ttl sekund

Payload Status List Tokenu (odpověď)

{
  "sub": "https://issuer.example/statuslists/employment-2026-q3",
  "iat": 1789200000,
  "exp": 1789804800,
  "ttl": 43200,
  "status_list": {
    "bits": 2,
    "lst": "eNrbuRgAAhcBXQ"
  }
}

sub opakuje vlastní URI seznamu, aby ověřovatel mohl potvrdit, že načetl správný token. iat a exp ohraničují platnost samotného tokenu. ttl, v sekundách, je maximální doba, po kterou smí ověřovatel používat uloženou kopii, než musí seznam načíst znovu.

Dekódování bitu

lst je bajtové pole, kódované jako base64url a komprimované pomocí DEFLATE ve formátu dat zlib, které ověřovatel nejprve dekomprimuje. bits udává, kolik bitů zabírá každý průkaz v seznamu: 1, 2, 4 nebo 8. Při bits: 2 se průkaz s číslem idx nachází v bajtu idx * 2 / 8 a ověřovatel na tomto posunu čte dva bity, aby získal hodnotu stavu.

Praktický příklad: idx 4271, bits: 2

bit_offset = idx * bits = 4271 * 2 = 8542
byte_index = bit_offset / 8 = 1067
bit_in_byte = bit_offset % 8 = 6

Ověřovatel přečte bajt 1067 dekomprimovaného pole, extrahuje dva bity počínaje bitem 6 a výsledek porovná s tabulkou hodnot níže.

Hodnota	Význam
0x00	VALID
0x01	INVALID
0x02	SUSPENDED
0x03, 0x0C-0x0F	Aplikačně specifické / rezervované

Zobrazené hodnoty předpokládají bits: 2. Při bits: 1 se vejdou pouze VALID (0) a INVALID (1); bits: 4 a bits: 8 ponechávají více prostoru pro aplikačně specifické hodnoty.

Proč seznam zůstává malý

Reálné statusové seznamy jsou převážně tvořeny nulami, protože většina průkazů, které kdy vydavatel vydal, je stále platná, a řada stejných bitů se dobře komprimuje. Komprese DEFLATE nad surovým bitovým řetězcem umožňuje udržet seznam pokrývající statisíce průkazů na velikosti několika kilobajtů při přenosu, což dělá načtení celého seznamu, místo dotazování vydavatele na jeden průkaz, prakticky proveditelným.

Agregace: předčasné objevování seznamů

Vydavatel může volitelně přidat do objektu Status List položku aggregation_uri, která odkazuje na koncový bod uvádějící URI všech Status List Tokenů, které publikuje. Ověřovatel, který chce seznamy předem načíst a uložit do mezipaměti dříve, než je bude potřebovat, místo aby každý objevoval z prvního průkazu, který na něj odkazuje, může místo toho použít tento koncový bod. Jde o volitelnou funkci, hlavní tok popsaný výše na ní nezávisí.

Související pojmy

Status List Zrušení Vydavatel Ověřovatel SD-JWT

Často kladené otázky

Načítá ověřovatel pro každý kontrolovaný průkaz samostatný seznam?

Ne, jeden Status List Token pokrývá všechny průkazy, které do něj vydavatel umístil, potenciálně statisíce. Ověřovatel načte stejný token jednou a pro každý kontrolovaný průkaz čte jiný bit, poté používá uloženou kopii až ttl sekund, než ji načte znovu.

Může vydavatel zjistit, který průkaz ověřovatel vyhledával?

Ne. Ověřovatel stáhne celý komprimovaný bitový řetězec v jednom požadavku a potřebný bit čte lokálně, takže požadavek, který vydavatel vidí, neobsahuje žádný index ani identifikátor průkazu, pouze GET na samotný seznam.

Jaký je rozdíl mezi stavy suspended a invalid?

INVALID (0x01) je označení, kterým referenční registr specifikace značí trvale zneplatněný průkaz. SUSPENDED (0x02) je samostatný, vratný stav, který může vydavatel rovněž nastavit a později zrušit, například během řešení sporu. Rozlišení mezi nimi vyžaduje alespoň dva bity na záznam (bits: 2), takže Status List Token s bits: 1 dokáže rozlišit pouze platný od neplatného.

K čemu slouží aggregation_uri?

Je to volitelný odkaz uvnitř objektu Status List na agregační koncový bod, který uvádí URI všech Status List Tokenů daného vydavatele. Ověřovatel, který chce svou mezipaměť předem zahřát nebo objevit seznamy, které ještě nezná, může místo čekání na to, až mu je uvede nějaký průkaz, načíst tento koncový bod.

Zdroje

IETF Token Status List (draft-ietf-oauth-status-list)

Tato stránka má informativní charakter a nepředstavuje právní poradenství. Pro závazné pokyny nahlédněte přímo do specifikace IETF.

Promluvte si s námi o integraci EUDI Wallet