Unieważnianie za pomocą Status List wyjaśnione
Weryfikator, który właśnie otrzymał poświadczenie, musi wiedzieć, czy wystawca nadal je uznaje. Token Status List odpowiada na to bez konieczności kontaktowania się weryfikatora z wystawcą w sprawie tego konkretnego poświadczenia: oświadczenie status wewnątrz poświadczenia wskazuje na zwartą listę, a pojedynczy bit tej listy zawiera odpowiedź.
Oświadczenie status wewnątrz poświadczenia
Wystawca obsługujący Token Status List dodaje oświadczenie status do poświadczenia w momencie jego wystawienia. Zawiera ono dwa elementy: idx, czyli indeks, który to poświadczenie zajmuje na liście, oraz uri, czyli adres Status List Token, który je przechowuje. Nic innego w poświadczeniu się nie zmienia; oświadczenie jest jedynie wskaźnikiem.
Wystawca
Przypisuje poświadczeniu indeks i osadza oświadczenie status
Oświadczenie dodawane jest jednorazowo, w momencie wystawienia, i nigdy nie zmienia się przez cały okres ważności poświadczenia
Oświadczenie status (wewnątrz poświadczenia)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Pobieranie Status List Token
W momencie przedstawienia poświadczenia weryfikator pobiera uri z oświadczenia status. Odpowiedzią jest podpisany Status List Token: JWT z nagłówkiem typ o wartości statuslist+jwt (lub odpowiednik CWT), udostępniany jako application/statuslist+jwt. Jego treść zawiera skompresowany ciąg bitów oraz zwykle ttl, który informuje weryfikatora, jak długo może buforować wynik, zanim będzie musiał pobrać go ponownie.
Weryfikator
Odczytuje idx i uri z oświadczenia status w dopiero co przedstawionym poświadczeniu
GET uri
Pobiera Status List Token, buforując go przez maksymalnie ttl sekund
Treść Status List Token (odpowiedź)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub powtarza własny URI listy, dzięki czemu weryfikator może potwierdzić, że pobrał właściwy token. iat i exp ograniczają ważność samego tokenu. ttl, w sekundach, to maksymalny czas, przez jaki weryfikator może ponownie wykorzystywać zbuforowaną kopię, zanim będzie musiał ponownie pobrać listę.
Dekodowanie bitu
lst to tablica bajtów, zakodowana w base64url i skompresowana algorytmem DEFLATE w formacie danych zlib, którą weryfikator najpierw dekompresuje. bits określa, ile bitów zajmuje każde poświadczenie na liście: 1, 2, 4 lub 8. Przy bits: 2 poświadczenie o numerze idx znajduje się w bajcie idx * 2 / 8, a weryfikator odczytuje dwa bity pod tym przesunięciem, aby uzyskać wartość statusu.
Przykład: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Weryfikator odczytuje bajt 1067 zdekompresowanej tablicy, wyodrębnia dwa bity zaczynając od bitu 6, i porównuje wynik z poniższą tabelą wartości.
| Wartość | Znaczenie |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Specyficzne dla aplikacji / zarezerwowane |
Przedstawione wartości zakładają bits: 2. Przy bits: 1 mieszczą się tylko VALID (0) i INVALID (1); bits: 4 i bits: 8 pozostawiają więcej miejsca na wartości specyficzne dla aplikacji.
Dlaczego lista pozostaje mała
Rzeczywiste listy statusów składają się głównie z zer, ponieważ większość poświadczeń, jakie kiedykolwiek wystawił wystawca, nadal jest ważna, a ciąg identycznych bitów dobrze się kompresuje. To kompresja DEFLATE surowego ciągu bitów sprawia, że lista obejmująca setki tysięcy poświadczeń zajmuje w transmisji zaledwie kilka kilobajtów, co czyni pobranie całej listy, zamiast pytania wystawcy o jedno poświadczenie, praktycznym rozwiązaniem.
Agregacja: wcześniejsze odkrywanie list
Wystawca może opcjonalnie dodać aggregation_uri do obiektu Status List, wskazujący punkt końcowy zawierający adresy URI wszystkich publikowanych przez niego Status List Token. Weryfikator, który chce wcześniej pobrać i zbuforować listy, zanim będą potrzebne, zamiast odkrywać każdą z nich na podstawie pierwszego odwołującego się do niej poświadczenia, może zamiast tego skorzystać z tego punktu końcowego. Jest to opcjonalne; nic w opisanym powyżej podstawowym przepływie od tego nie zależy.
Powiązane pojęcia
Najczęściej zadawane pytania
Czy weryfikator pobiera osobną listę dla każdego sprawdzanego poświadczenia?
Nie, jeden Status List Token obejmuje wszystkie poświadczenia, które umieścił w nim wystawca, potencjalnie setki tysięcy. Weryfikator pobiera ten sam token raz i odczytuje inny bit dla każdego sprawdzanego poświadczenia, a następnie ponownie wykorzystuje zbuforowaną kopię przez maksymalnie ttl sekund, zanim pobierze ją ponownie.
Czy wystawca może stwierdzić, które poświadczenie sprawdził weryfikator?
Nie. Weryfikator pobiera cały skompresowany ciąg bitów w jednym żądaniu i odczytuje potrzebny bit lokalnie, więc żądanie widziane przez wystawcę nie zawiera ani indeksu, ani identyfikatora poświadczenia, a jedynie GET do samej listy.
Jaka jest różnica między suspended a invalid?
INVALID (0x01) to sposób, w jaki rejestr referencyjny specyfikacji oznacza trwale unieważnione poświadczenie. SUSPENDED (0x02) to odrębny, odwracalny stan, który wystawca może również ustawić, a później usunąć, na przykład podczas wyjaśniania sporu. Rozróżnienie ich wymaga co najmniej dwóch bitów na wpis (bits: 2), więc Status List Token korzystający z bits: 1 może rozróżnić jedynie ważne od nieważnego.
Do czego służy aggregation_uri?
To opcjonalny wskaźnik wewnątrz obiektu Status List do punktu agregującego, który wylicza adresy URI wszystkich Status List Token danego wystawcy. Weryfikator, który chce z wyprzedzeniem rozgrzać swój bufor lub odkryć listy, których jeszcze nie widział, może pobrać ten punkt końcowy zamiast czekać, aż wskaże go jakieś poświadczenie.
Źródła
Ta strona ma charakter informacyjny i nie stanowi porady prawnej. Aby uzyskać wiążące wytyczne, zapoznaj się bezpośrednio ze specyfikacją IETF.