From bdabba1b29800cd18d440612bc0a30be01b799c8 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 8 Oct 2024 12:13:13 +0200 Subject: [PATCH] editorial fixes --- draft-ietf-oauth-status-list.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 3626525..9c45e3f 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -778,6 +778,7 @@ Once the Relying Party receives the Referenced Token, this enables him to reques TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture This behaviour could be mitigated by: + - regular re-issuance of the Referenced Token, see [](#implementation-lifecycle). ## Observability of Outsiders {#privacy-outsider} @@ -785,8 +786,9 @@ This behaviour could be mitigated by: Outside actors may analyse the publicly available Status Lists to get information on the internal processes of the Issuer and his related business. This data may allow inferences on the total number of issued Reference Tokens and the revocation rate. Additionally, actors may regularly fetch this data or use the historic data functionality to learn how these numbers change over time. This behaviour could be mitigated by: + - disable the historical data feature (TODO:link) -- disable the Status List Aggregation {#batch-fetching} +- disable the Status List Aggregation []{#batch-fetching} - choose non-sequential, pseudo-random or random indices - use decoy entries to obfuscate the real number of Referenced Tokens within a Status List - choose to deploy and utilize multiple Status Lists simultaneously