From a979909df4cb22747c2d5e95e29d7b772f98de05 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sun, 22 Oct 2023 21:36:56 +0200 Subject: [PATCH 1/3] design considerations --- draft-ietf-oauth-status-list.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 8af5cce..33ce2c0 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -66,7 +66,18 @@ The following diagram depicts the basic conceptual relationship. Revocation mechanisms are an essential part for most identity ecosystems. In the past, revocation of X.509 TLS certificates has been proven difficult. Traditional certificate revocation lists (CRLs) have limited scalability; Online Certificate Status Protocol (OCSP) has additional privacy risks, since the client is leaking the requested website to a third party. OCSP stapling is addressing some of these problems at the cost of less up-to-date data. Modern approaches use accumulator-based revocation registries and Zero-Knowledge-Proofs to accommodate for this privacy gap, but face scalability issues again. -This specification seeks to find a balance between scalability, security, and privacy by minimizing the status information to mere bits (often a single bit) and compressing the resulting binary data. Thereby, a Status List may contain statuses of 100,000 or more Referenced Tokens, but still remain relatively small. Placing large amounts of Referenced Tokens into the same list also enables herd privacy relative to the Issuer. +This specification seeks to find a balance between scalability, security, and privacy by minimizing the status information to mere bits (often a single bit) and compressing the resulting binary data. Thereby, a Status List may contain statuses of many thousands or millions Referenced Tokens while remaining as small as possible. Placing large amounts of Referenced Tokens into the same list also enables herd privacy relative to the Issuer. + +## Design Considerations + +The decisions taken in this specification aim to achieve the following design goals: + +* the specification shall favor a simple and easy to understand concept +* the specification shall be easy, fast and secure to implement in all major programming languages +* the specification shall be optimized to support the most common use cases and avoid unneccessary complexity of corner cases +* the Status List shall scale up to millions of tokens to support large scale government or enterprise use cases +* the Status List shall enable caching policies and offline support +* the specification shall support JSON and CBOR based tokens # Conventions and Definitions From e9a108277d528958bf4381f030c8f0bc28394da7 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 16 Nov 2023 16:55:43 +0100 Subject: [PATCH 2/3] Update draft-ietf-oauth-status-list.md --- draft-ietf-oauth-status-list.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 33ce2c0..49389ea 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -78,6 +78,7 @@ The decisions taken in this specification aim to achieve the following design go * the Status List shall scale up to millions of tokens to support large scale government or enterprise use cases * the Status List shall enable caching policies and offline support * the specification shall support JSON and CBOR based tokens +* the specification shall not specify key resolution or trust frameworks # Conventions and Definitions From 6b905e6891f13526fa4a7daf31304e31a13b837e Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 15 Jan 2024 08:09:41 +0100 Subject: [PATCH 3/3] Update draft-ietf-oauth-status-list.md --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 49389ea..0db7b4d 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -475,7 +475,7 @@ for their valuable contributions, discussions and feedback to this specification {:numbered="false"} -01 - +* add design consideration to the introduction * Changing compression from gzip to zlib * Change typo in Status List Token sub claim description