From 7a3e454701b168cdfa024d210b39ecf7b8e18573 Mon Sep 17 00:00:00 2001 From: Andrii Deinega Date: Wed, 9 Jul 2025 16:31:58 -0500 Subject: [PATCH 1/4] grammar fixes --- draft-ietf-oauth-status-list.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index d60f3ba..a2e61ed 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -956,7 +956,7 @@ Alternatively, the Status Issuer may use the same web-based key resolution that │ Status Provider │ └─────────────────┘ ~~~ -If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by an Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize [extended key usage](#eku). +If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by a Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize [extended key usage](#eku). ~~~ ascii-art ┌───────────────────────┐ @@ -1116,7 +1116,7 @@ When fetching a Status List Token, Relying Parties must carefully evaluate how l - After initial fetching, the Relying Party checks for updates at time of `iat` + `ttl`. This method ensures the most up-to-date information for critical use cases. The Relying Party should account a minimal offset due to the signing and distribution process of the Status Issuer. - If no `ttl` is given, then Relying Party SHOULD check for updates latest after time of `exp`. -Ultimately, its the Relying Parties decision how often to check for updates, ecosystems may define there own guidelines and policies for updating the Status List information. +Ultimately, it's the Relying Parties decision how often to check for updates, ecosystems may define their own guidelines and policies for updating the Status List information. The following diagram illustrates the relationship between these claims and how they are designed to influence caching: From 5012e175ee33fec25fcc514c312ec2e8f249323f Mon Sep 17 00:00:00 2001 From: Andrii Deinega Date: Wed, 9 Jul 2025 16:47:49 -0500 Subject: [PATCH 2/4] 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 a2e61ed..2a2e36b 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -250,7 +250,7 @@ base64url: # Status List {#status-list} -A Status List is a data structure that contains the statuses of many Referenced Tokens represented by one or multiple bits. The [first section](#status-list-byte-array) describes how to construct a compressed byte array that is the base component for the Status List data structure. The second and third section describe how to encode such a Status List in JSON and CBOR representation. +A Status List is a data structure that contains the statuses of many Referenced Tokens represented by one or multiple bits. The [first section](#status-list-byte-array) describes how to construct a compressed byte array that is the base component for the Status List data structure. The second and third sections describe how to encode such a Status List in JSON and CBOR representations. ## Compressed Byte Array {#status-list-byte-array} From 4bdefdcf650047740004f092bf6abbd64e3bf865 Mon Sep 17 00:00:00 2001 From: Andrii Deinega Date: Wed, 9 Jul 2025 17:24:59 -0500 Subject: [PATCH 3/4] Update draft-ietf-oauth-status-list.md Mnr rewording for clarity (I hope). --- draft-ietf-oauth-status-list.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 2a2e36b..bae3874 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -176,13 +176,13 @@ The following diagram depicts the relationship between the involved roles (Relyi ~~~ -Status Lists may be composed to express a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. +Status Lists can be used to express a variety of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. ## Example Use Cases -An example of the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of {{RFC6749}}. Token Introspection {{RFC7662}} defines a way to determine the status of an issued access token, but it requires the party trying to validate the state of access tokens to directly contact the Issuer of the access tokens for each token validation. In contrast, the mechanism defined in this specification allows a party to fetch the status for many tokens, reducing interactions with the Issuer significantly for better scalability and providing better privacy as the Issuer does not learn which specific access token is being verified (herd anonymity). +An example of the usage of a Status List is to manage the statuses of issued access tokens as defined in section 1.4 of {{RFC6749}}. Token Introspection {{RFC7662}} provides a method to determine the status of an issued access token, but it necessitates the party attempting to validate the state of access tokens to directly contact the Issuer of each token for validation. In contrast, the mechanism defined in this specification allows a party to retrieve the statuses for many tokens, reducing interactions with the Issuer substantially. This not only improves scalability but also enhances privacy by preventing the Issuer from gaining knowledge of access tokens being verified (herd anonymity). Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model {{SD-JWT.VC}}. From fb79496309e1a5607c9d5282f06fede838c6071d Mon Sep 17 00:00:00 2001 From: Andrii Deinega Date: Wed, 9 Jul 2025 22:12:44 -0500 Subject: [PATCH 4/4] Update draft-ietf-oauth-status-list.md --- draft-ietf-oauth-status-list.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index bae3874..e6c48db 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -869,9 +869,10 @@ An Issuer MAY support any of these mechanisms: ## Issuer Metadata -The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID or within Issuer certificates or trust lists (such as VICAL as defined in Annex C of {{ISO.mdoc}}). If the Issuer is an OAuth Authorization Server according to {{RFC6749}}, it is RECOMMENDED to use `status_list_aggregation_endpoint` for its metadata defined by {{RFC8414}}. The Issuer MAY limit the Status List Tokens listed by a Status List Aggregation to a particular type of Referenced Token. +The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID Connect, or within Issuer certificates or trust lists (such as VICAL as defined in Annex C of {{ISO.mdoc}}). If the Issuer is an OAuth Authorization Server according to {{RFC6749}}, it is RECOMMENDED to use `status_list_aggregation_endpoint` for its metadata defined by {{RFC8414}}. The Issuer MAY limit the Status List Tokens listed by a Status List Aggregation to a particular type of Referenced Token. + +The concrete implementation details depend on the specific ecosystem and are out of scope of this specification. -The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification. ## Status List Parameter