Merge branch 'main' into 56-add-option-for-plain-status-list-unsigned

Author: paulbastian

draft-ietf-oauth-status-list.md

@@ -1,5 +1,5 @@
 ---
-title: "OAuth Status List"
+title: "Token Status List"
 category: info
 
 docname: draft-ietf-oauth-status-list-latest
@@ -34,6 +34,8 @@ normative:
   RFC9110: RFC9110
   RFC9111: RFC9111
 informative:
+  RFC6749: RFC6749
+  RFC7662: RFC7662
 
 --- abstract
 
@@ -46,8 +48,11 @@ The status list data structures themselves are also represented as JWTs or CWTs.
 
 JSON Web Tokens (JWTs) {{RFC7519}} and CBOR Web Tokens (CWTs) {{RFC8392}} as secure token formats, have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer.
 
-This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided by an endpoint or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing 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. The document also defines how an issuer of a Referenced Token references a Status List (Token). The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model to express the status of verifiable credentials (Referenced Tokens) issued by an issuer.
+This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided by an endpoint or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing 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. The document also defines how an issuer of a Referenced Token references a Status List (Token). 
 
+An example for 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 another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation.
+
+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.
 The following diagram depicts the basic conceptual relationship.
 
 ~~~ ascii-art
@@ -537,6 +542,7 @@ for their valuable contributions, discussions and feedback to this specification
 * add option to return an unsigned Status List
 * Changing compression from gzip to zlib
 * Change typo in Status List Token sub claim description
+* Add access token as an example use-case
 
 -00