Status List anulēšana skaidrota
Pārbaudītājam, kas tikko saņēmis akreditācijas datu, jāzina, vai izdevējs joprojām stāv aiz tā. Token Status List uz to atbild bez tā, ka pārbaudītājam būtu jāsazinās ar izdevēju par šo konkrēto akreditācijas datu: statusa apliecinājums akreditācijas datā norāda uz kompaktu sarakstu, un viens šā saraksta bits sniedz atbildi.
Statusa apliecinājums akreditācijas datā
Izdevējs, kas atbalsta Token Status List, izdošanas brīdī pievieno akreditācijas datam statusa apliecinājumu. Tas satur divas lietas: idx, indeksu, kas šim akreditācijas datam pieder sarakstā, un uri, adresi Status List Token, kurā tas atrodas. Nekas cits akreditācijas datā nemainās; apliecinājums ir tikai rādītājs.
Izdevējs
Piešķir akreditācijas datam indeksu un iegulda statusa apliecinājumu
Apliecinājums tiek pievienots vienreiz, izdošanas brīdī, un nekad nemainās visā akreditācijas datu derīguma laikā
Statusa apliecinājums (akreditācijas datā)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Status List Token iegūšana
Uzrādīšanas brīdī pārbaudītājs iegūst uri no statusa apliecinājuma. Atbilde ir parakstīts Status List Token: JWT ar typ galveni statuslist+jwt (vai tā CWT ekvivalentu), kas tiek sniegts kā application/statuslist+jwt. Tā saturs ietver saspiesto bitu virkni un parasti arī ttl, kas informē pārbaudītāju, cik ilgi tas drīkst kešatmiņā glabāt rezultātu, pirms tas jāiegūst no jauna.
Pārbaudītājs
Nolasa idx un uri no statusa apliecinājuma (status claim) tikko uzrādītajā akreditācijas datā
GET uri
Iegūst Status List Token, saglabājot to kešatmiņā līdz ttl sekundēm
Status List Token saturs (atbilde)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub atkārto paša saraksta URI, lai pārbaudītājs varētu apstiprināt, ka ieguvis pareizo tokenu. iat un exp ierobežo paša tokena derīgumu. ttl sekundēs ir maksimālais laiks, cik ilgi pārbaudītājs drīkst atkārtoti izmantot kešatmiņā saglabāto kopiju, pirms tam jāiegūst saraksts no jauna.
Bita dekodēšana
lst ir baitu masīvs, kodēts base64url formātā un saspiests ar DEFLATE zlib datu formātā; pārbaudītājs to vispirms atspiež. bits norāda, cik bitu aizņem katrs akreditācijas dati sarakstā: 1, 2, 4 vai 8. Ja bits: 2, akreditācijas dati ar numuru idx atrodas baitā idx * 2 / 8, un pārbaudītājs šajā nobīdē nolasa divus bitus, lai iegūtu statusa vērtību.
Piemērs: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Pārbaudītājs nolasa atspiestā masīva baitu 1067, izgūst divus bitus, sākot no bita 6, un salīdzina rezultātu ar zemāk redzamo vērtību tabulu.
| Vērtība | Nozīme |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Lietojumam specifisks / rezervēts |
Attēlotās vērtības pieņem bits: 2. Ar bits: 1 der tikai VALID (0) un INVALID (1); bits: 4 un bits: 8 atstāj vairāk brīvas telpas lietojumam specifiskām vērtībām.
Kāpēc saraksts paliek mazs
Reālie statusa saraksti pārsvarā sastāv no nullēm, jo lielākā daļa akreditācijas datu, ko izdevējs jebkad izsniedzis, joprojām ir derīgi, un vienādu bitu virkne labi saspiežas. DEFLATE saspiešana pār neapstrādāto bitu virkni ir tas, kas ļauj sarakstam, kurš aptver simtiem tūkstošu akreditācijas datu, tīklā aizņemt tikai dažus kilobaitus, un tieši tas padara praktisku visa saraksta iegūšanu tā vietā, lai izdevējam jautātu par vienu akreditācijas datu.
Apkopošana: sarakstu atklāšana iepriekš
Izdevējs pēc izvēles var pievienot aggregation_uri Status List objektam, norādot uz galapunktu, kas uzskaita visu tā publicēto Status List Token URI. Pārbaudītājs, kurš vēlas iepriekš iegūt un kešatmiņā saglabāt sarakstus, pirms tie ir vajadzīgi, nevis katru atklāt no pirmā akreditācijas datu, kas uz to atsaucas, var izmantot šo galapunktu. Tas ir izvēles; pamata plūsma iepriekš aprakstītajā veidā no tā nav atkarīga.
Saistītie termini
Biežāk uzdotie jautājumi
Vai pārbaudītājs katram pārbaudāmajam akreditācijas datam iegūst atsevišķu sarakstu?
Nē, viens Status List Token aptver visus akreditācijas datus, ko izdevējs tajā iekļāvis, iespējams simtiem tūkstošu. Pārbaudītājs vienreiz iegūst to pašu tokenu un katram pārbaudāmajam akreditācijas datam nolasa citu bitu, pēc tam atkārtoti izmanto kešatmiņā saglabāto kopiju līdz ttl sekundēm, pirms iegūst to no jauna.
Vai izdevējs var uzzināt, kuru akreditācijas datu pārbaudītājs meklējis?
Nē. Pārbaudītājs vienā pieprasījumā lejupielādē visu saspiesto bitu virkni un lokāli nolasa nepieciešamo bitu, tāpēc pieprasījumā, ko redz izdevējs, nav ne indeksa, ne akreditācijas datu identifikatora, bet tikai GET pašam sarakstam.
Kāda ir atšķirība starp suspended un invalid?
INVALID (0x01) ir apzīmējums, ar kuru specifikācijas atsauces reģistrs marķē neatgriezeniski anulētu akreditācijas datu. SUSPENDED (0x02) ir atsevišķs, atgriezenisks statuss, ko izdevējs var arī noteikt un vēlāk atcelt, piemēram, kamēr tiek izmeklēts strīds. Lai tos atšķirtu, nepieciešami vismaz divi biti katram ierakstam (bits: 2), tāpēc Status List Token, kas izmanto bits: 1, spēj atšķirt tikai derīgu no nederīga.
Kam paredzēts aggregation_uri?
Tas ir izvēles rādītājs Status List objektā uz apkopošanas galapunktu, kas uzskaita visu attiecīgā izdevēja Status List Token URI. Pārbaudītājs, kurš vēlas iepriekš uzsildīt kešatmiņu vai atklāt vēl neredzētus sarakstus, var iegūt šo galapunktu, nevis gaidīt, kad kāds akreditācijas dati to nosauks.
Avoti
Šī lapa ir informatīva un nav uzskatāma par juridisku konsultāciju. Pēc autoritatīviem norādījumiem vērsieties tieši pie IETF specifikācijas.