From ef883f2d1887589b96ebde50c82b9331e93307e4 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 29 Nov 2024 04:54:32 +0000 Subject: [PATCH] Script updating gh-pages from bab76c8. [ci skip] --- index.html | 9 + .../draft-ietf-oauth-status-list.html | 3614 +++++++++++++++++ tl/issue-182/draft-ietf-oauth-status-list.txt | 2184 ++++++++++ tl/issue-182/index.html | 45 + 4 files changed, 5852 insertions(+) create mode 100644 tl/issue-182/draft-ietf-oauth-status-list.html create mode 100644 tl/issue-182/draft-ietf-oauth-status-list.txt create mode 100644 tl/issue-182/index.html diff --git a/index.html b/index.html index 126a146..5f4d486 100644 --- a/index.html +++ b/index.html @@ -194,6 +194,15 @@

Preview for branch pb/relax_mac

diff with main +

Preview for branch tl

+

Preview for branch tl/issue-182

+ + + + + + +
Token Status Listplain textdiff with main

Preview for branch oauth-metadata

diff --git a/tl/issue-182/draft-ietf-oauth-status-list.html b/tl/issue-182/draft-ietf-oauth-status-list.html new file mode 100644 index 0000000..4343a9d --- /dev/null +++ b/tl/issue-182/draft-ietf-oauth-status-list.html @@ -0,0 +1,3614 @@ + + + + + + +Token Status List + + + + + + + + + + + + + +
+ + + + + + + + + + +
Internet-DraftToken Status ListNovember 2024
Looker, et al.Expires 2 June 2025[Page]
+
+
+
+
Workgroup:
+
Network Working Group
+
Internet-Draft:
+
draft-ietf-oauth-status-list-latest
+
Published:
+
+ +
+
Intended Status:
+
Informational
+
Expires:
+
+
Authors:
+
+
+
T. Looker
+
MATTR
+
+
+
P. Bastian
+
+
+
C. Bormann
+
Robert Bosch GmbH
+
+
+
+
+

Token Status List

+
+

Abstract

+

This specification defines status list data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption(COSE), such as JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs) and ISO mdoc. +Status Lists are provided in the form of JWTs or CWTs.

+
+
+

+About This Document +

+

This note is to be removed before publishing as an RFC.

+

+ The latest revision of this draft can be found at https://oauth-wg.github.io/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html. + Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/.

+

Source for this draft and an issue tracker can be found at + https://github.com/oauth-wg/draft-ietf-oauth-status-list.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 2 June 2025.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. Introduction +

+

Token formats secured by JOSE [IANA.JOSE] or COSE [RFC9052], such as JSON Web Tokens (JWTs) [RFC7519], CBOR Web Tokens (CWTs) [RFC8392] and ISO mdoc [ISO.mdoc], 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 JWT and CWT formats that describe the individual statuses of multiple Referenced Tokens, which themselves are most commonly data structures secured by JOSE or COSE. 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 is provided within a Status List Token protected by cryptographic signature or MAC and this document defines its representations in JWT and CWT format. 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 [SD-JWT.VC]. +The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of [SD-JWT.VC]):

+
+
+           issue                 present
+           Referenced            Referenced
+┌────────┐ Token      ┌────────┐ Token      ┌───────────────┐
+│ Issuer ├───────────►│ Holder ├───────────►│ Relying Party │
+└─┬──────┘            └────────┘            └──┬────────────┘
+  ▼ update status                              │
+┌───────────────┐                              │
+│ Status Issuer │                              │
+└─┬─────────────┘                              │
+  ▼ provide Status List                        │
+┌─────────────────┐         fetch Status List  │
+│ Status Provider │◄───────────────────────────┘
+└─────────────────┘
+
+
+
+

An Issuer issues Referenced Tokens to a Holder, the Holder uses and presents those Referenced Tokens to a Relying Party. The Issuer gives updated status information to the Status Issuer, who creates a Status List Token. The Status Issuer provides the Status List Token to the Status Provider, who serves the Status List Token on a public, resolvable endpoint. The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity. If not further specified, the term Issuer may refer to an entity acting for all three roles.

+

The following diagram depicts the relationship between the artifacts:

+
+
+┌────────────────┐  describes status ┌──────────────────┐
+│  Status List   ├──────────────────►│ Referenced Token │
+│ (JSON or CBOR) │◄──────────────────┤  (JOSE or COSE)  │
+└─────┬──────────┘    references     └──────────────────┘
+      │
+      │ embedded in
+      ▼
+┌───────────────────┐
+│ Status List Token │
+│  (JWT or CWT)     │
+└───────────────────┘
+
+
+
+

The Referenced Token is referenced by the Status List, which described the status of the Referenced Token. The Status List is embedded and secured within a Status List Token.

+
+
+

+1.1. Rationale +

+

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 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 Status Provider.

+

This specification establishes the IANA "Status Mechanism Methods" registry for status mechanism and registers the members defined by this specification. Other specifications can register other members used for status retrieval.

+
+
+
+
+

+1.2. 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 unnecessary 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

    +
    • +
  • +

    the specification shall not specify key resolution or trust frameworks

    +
    • +
  • +

    the specification shall design an extension point to convey information about the status of a token that can be re-used by other mechanisms

    +
    • +
+
+
+
+
+
+
+

+2. Conventions and Definitions +

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", +"MAY", and "OPTIONAL" in this document are to be interpreted as +described in BCP 14 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.

+
+
+
+
+

+3. Terminology +

+
+
Issuer:
+
+

An entity that issues the Referenced Token.

+
+
+
Status Issuer:
+
+

An entity that issues the Status List Token about the status information of the Referenced Token. This role may be fulfilled by the Issuer.

+
+
+
Status Provider:
+
+

An entity that provides the Status List Token on a public endpoint. This role may be fulfilled by the Status Issuer.

+
+
+
Holder:
+
+

An entity that receives Referenced Tokens form the Issuer and presents them to Relying Parties.

+
+
+
Relying Party:
+
+

An entity that relies on the Status List Token to validate the status of the Referenced Token. Also known as Verifier.

+
+
+
Status List:
+
+

An object in JSON or CBOR representation containing a bit array that lists the statuses of many Referenced Tokens.

+
+
+
Status List Token:
+
+

A token in JWT or CWT representation that contains a cryptographically secured Status List.

+
+
+
Referenced Token:
+
+

A cryptographically secured data structure which contains a reference to a Status List Token. It is RECOMMENDED to use JSON [RFC8259] with JOSE as defined in [RFC7515] or CBOR [RFC8949] with COSE as defined in [RFC9052]. The information from the contained Status List gives the Relying Party additional information about the current status of the Referenced Token. Examples for Referenced Tokens are SD-JWT VC and ISO mdoc.

+
+
+
base64url:
+
+

Denotes the URL-safe base64 encoding without padding as defined in Section 2 of [RFC7515] as "Base64url Encoding".

+
+
+
+
+
+
+
+

+4. Status List +

+

A Status List is a byte array that contains the statuses of many Referenced Tokens represented by one or multiple bits. A common representation of a Status List is composed by the following algorithm:

+
    +
  1. +

    Each status of a Referenced Token MUST be represented with a bit-size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for a Referenced Token are possible, depending on the bit-size. This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone.

    +
    2. +
  2. +

    The overall Status List is encoded as a byte array. Depending on the bit-size, each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1). The status of each Referenced Token is identified using the index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with "size" - 1 (being the last valid entry). The bits within an array are counted from least significant bit "0" to the most significant bit ("7"). All bits of the byte array at a particular index are set to a status value.

    +
    3. +
  3. +

    The byte array is compressed using DEFLATE [RFC1951] with the ZLIB [RFC1950] data format. Implementations are RECOMMENDED to use the highest compression level available.

    +
    4. +
+

The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the uncompressed byte array:

+
+
+status[0] = 1
+status[1] = 0
+status[2] = 0
+status[3] = 1
+status[4] = 1
+status[5] = 1
+status[6] = 0
+status[7] = 1
+status[8] = 1
+status[9] = 1
+status[10] = 0
+status[11] = 0
+status[12] = 0
+status[13] = 1
+status[14] = 0
+status[15] = 1
+
+
+

These bits are concatenated:

+
+
+byte             0                  1               2
+bit       7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0    7
+         +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+  +-+...
+values   |1|0|1|1|1|0|0|1|  |1|0|1|0|0|0|1|1|  |0|...
+         +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+  +-+...
+index     7 6 5 4 3 2 1 0   15   ...  10 9 8   23
+         \_______________/  \_______________/
+                0xB9               0xA3
+
+
+
+
+
+

+4.1. Status List in JSON Format +

+

This section defines the data structure for a JSON-encoded Status List:

+
    +
  • +

    status_list: REQUIRED. JSON Object that contains a Status List. It MUST contain at least the following claims:

    +
      +
    • +

      bits: REQUIRED. JSON Integer specifying the number of bits per Referenced Token in the Status List (lst). The allowed values for bits are 1,2,4 and 8.

      +
      • +
    • +

      lst: REQUIRED. JSON String that contains the status values for all the Referenced Tokens it conveys statuses for. The value MUST be the base64url-encoded Status List as specified in Section 4.

      +
      • +
    • +

      aggregation_uri: OPTIONAL. JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token. See section Section 9 for further detail.

      +
      • +
    +
    • +
+

The following example illustrates the JSON representation of the Status List:

+
+
+byte_array = [0xb9, 0xa3]
+encoded:
+{
+  "bits": 1,
+  "lst": "eNrbuRgAAhcBXQ"
+}
+
+
+
+
+
+
+

+4.2. Status List in CBOR Format +

+

This section defines the data structure for a CBOR-encoded Status List:

+
    +
  • +

    The StatusList structure is a map (Major Type 5) and defines the following entries:

    +
      +
    • +

      bits: REQUIRED. Unsigned integer (Major Type 0) that contains the number of bits per Referenced Token in the Status List. The allowed values for bits are 1, 2, 4 and 8.

      +
      • +
    • +

      lst: REQUIRED. Byte string (Major Type 2) that contains the Status List as specified in Section 4.

      +
      • +
    • +

      aggregation_uri: OPTIONAL. Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token. See section Section 9 for further detail.

      +
      • +
    +
    • +
+

The following example illustrates the CBOR representation of the Status List in Hex:

+
+
+byte_array = [0xb9, 0xa3]
+encoded:
+a2646269747301636c73744a78dadbb918000217015d
+
+
+

The following is the CBOR Annotated Hex output of the example above:

+
+
+a2                              # map(2)
+  64                            #   string(4)
+    62697473                    #     "bits"
+  01                            #   uint(1)
+  63                            #   string(3)
+    6c7374                      #     "lst"
+  4a                            #   bytes(10)
+    78dadbb918000217015d        #     "xÚÛ¹\x18\x00\x02\x17\x01]"
+
+
+
+
+
+
+
+
+

+5. Status List Token +

+

A Status List Token embeds the Status List into a token that is cryptographically signed and protects the integrity of the Status List. This allows for the Status List Token to be hosted by third parties or be transferred for offline use cases.

+

This section specifies Status List Tokens in JSON Web Token (JWT) and CBOR Web Token (CWT) format.

+
+
+

+5.1. Status List Token in JWT Format +

+

The Status List Token MUST be encoded as a "JSON Web Token (JWT)" according to [RFC7519].

+

The following content applies to the JWT Header:

+
    +
  • +

    typ: REQUIRED. The JWT type MUST be statuslist+jwt.

    +
    • +
+

The following content applies to the JWT Claims Set:

+
    +
  • +

    sub: REQUIRED. As generally defined in [RFC7519]. The sub (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the uri claim contained in the status_list claim of the Referenced Token.

    +
    • +
  • +

    iat: REQUIRED. As generally defined in [RFC7519]. The iat (issued at) claim MUST specify the time at which the Status List Token was issued.

    +
    • +
  • +

    exp: OPTIONAL. As generally defined in [RFC7519]. The exp (expiration time) claim, if present, MUST specify the time at which the Status List Token is considered expired by the Status Issuer.

    +
    • +
  • +

    ttl: OPTIONAL. The ttl (time to live) claim, if present, MUST specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved. The value of the claim MUST be a positive number encoded in JSON as a number.

    +
    • +
  • +

    status_list: REQUIRED. The status_list (status list) claim MUST specify the Status List conforming to the rules outlined in Section 4.1.

    +
    • +
+

The following additional rules apply:

+
    +
  1. +

    The JWT MAY contain other claims.

    +
    2. +
  2. +

    The JWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject JWTs with an invalid signature.

    +
    3. +
  3. +

    Relying Parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" [RFC7519].

    +
    4. +
  4. +

    Application of additional restrictions and policy are at the discretion of the Relying Party.

    +
    5. +
+

The following is a non-normative example for a Status List Token in JWT format:

+
+
+{
+  "alg": "ES256",
+  "kid": "12",
+  "typ": "statuslist+jwt"
+}
+.
+{
+  "exp": 2291720170,
+  "iat": 1686920170,
+  "status_list": {
+    "bits": 1,
+    "lst": "eNrbuRgAAhcBXQ"
+  },
+  "sub": "https://example.com/statuslists/1",
+  "ttl": 43200
+}
+
+
+
+
+
+
+

+5.2. Status List Token in CWT Format +

+

The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to [RFC8392].

+

The following content applies to the CWT protected header:

+
    +
  • +

    16 (type): REQUIRED. The type of the CWT MUST be statuslist+cwt as defined in [RFC9596].

    +
    • +
+

The following content applies to the CWT Claims Set:

+
    +
  • +

    2 (subject): REQUIRED. As generally defined in [RFC8392]. The subject claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the uri claim contained in the status_list claim of the Referenced Token.

    +
    • +
  • +

    6 (issued at): REQUIRED. As generally defined in [RFC8392]. The issued at claim MUST specify the time at which the Status List Token was issued.

    +
    • +
  • +

    4 (expiration time): OPTIONAL. As generally defined in [RFC8392]. The expiration time claim, if present, MUST specify the time at which the Status List Token is considered expired by its issuer.

    +
    • +
  • +

    65534 (time to live): OPTIONAL. Unsigned integer (Major Type 0). The time to live claim, if present, MUST specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved. The value of the claim MUST be a positive number.

    +
    • +
  • +

    65533 (status list): REQUIRED. The status list claim MUST specify the Status List conforming to the rules outlined in Section 4.2.

    +
    • +
+

The following additional rules apply:

+
    +
  1. +

    The CWT MAY contain other claims.

    +
    2. +
  2. +

    The CWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject CWTs with an invalid signature.

    +
    3. +
  3. +

    Relying Parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" [RFC8392].

    +
    4. +
  4. +

    Application of additional restrictions and policy are at the discretion of the Relying Party.

    +
    5. +
+

The following is a non-normative example for a Status List Token in CWT format in Hex:

+
+
+d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168
+747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a
+648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb
+b918000217015d58404898b20c53c0f91e3db499bf8d0ee12ee6044b9456613a801d
+91c745abf4e7d551af39bcc78949591b5d4bc20066c2b38ede12ccbd8503b55de756
+ab6119dc41
+
+
+

The following is the CBOR Annotated Hex output of the example above:

+
+
+d2                              # tag(18)
+  84                            #   array(4)
+    53                          #     bytes(19)
+      a20126106e7374617475736c  #       "¢\x01&\x10nstatusl"
+      6973742b637774            #       "ist+cwt"
+    a1                          #     map(1)
+      04                        #       uint(4)
+      42                        #       bytes(2)
+        3132                    #         "12"
+    58 50                       #     bytes(80)
+      a502782168747470733a2f2f  #       "¥\x02x!https://"
+      6578616d706c652e636f6d2f  #       "example.com/"
+      7374617475736c697374732f  #       "statuslists/"
+      31061a648c5bea041a8898df  #       "1\x06\x1ad\x8c[ê\x04\x1a\x88\x98ß"
+      ea19fffe19a8c019fffda264  #       "ê\x19ÿþ\x19¨À\x19ÿý¢d"
+      6269747301636c73744a78da  #       "bits\x01clstJxÚ"
+      dbb918000217015d          #       "Û¹\x18\x00\x02\x17\x01]"
+    58 40                       #     bytes(64)
+      4898b20c53c0f91e3db499bf  #       "H\x98²\x0cSÀù\x1e=´\x99¿"
+      8d0ee12ee6044b9456613a80  #       "\x8d\x0eá.æ\x04K\x94Va:\x80"
+      1d91c745abf4e7d551af39bc  #       "\x1d\x91ÇE«ôçÕQ¯9¼"
+      c78949591b5d4bc20066c2b3  #       "Ç\x89IY\x1b]KÂ\x00f³"
+      8ede12ccbd8503b55de756ab  #       "\x8eÞ\x12̽\x85\x03µ]çV«"
+      6119dc41                  #       "a\x19ÜA"
+
+
+
+
+
+
+
+
+

+6. Referenced Token +

+
+
+

+6.1. Status Claim +

+

By including a "status" claim in a Referenced Token, the Issuer is referencing a mechanism to retrieve status information about this Referenced Token. The claim contains members used to reference to a Status List Token as defined in this specification. Other members of the "status" object may be defined by other specifications. This is analogous to "cnf" claim in Section 3.1 of [RFC7800] in which different authenticity confirmation methods can be included.

+
+
+
+
+

+6.2. Referenced Token in JOSE +

+

The Referenced Token MAY be encoded as a "JSON Web Token (JWT)" according to [RFC7519] or other formats based on JOSE.

+

The following content applies to the JWT Claims Set:

+
    +
  • +

    status: REQUIRED. The status (status) claim MUST specify a JSON Object that contains at least one reference to a status mechanism.

    +
      +
    • +

      status_list: REQUIRED when the status mechanism defined in this specification is used. It contains a reference to a Status List Token. It MUST at least contain the following claims:

      +
        +
      • +

        idx: REQUIRED. The idx (index) claim MUST specify an Integer that represents the index to check for status information in the Status List for the current Referenced Token. The value of idx MUST be a non-negative number, containing a value of zero or greater.

        +
        • +
      • +

        uri: REQUIRED. The uri (URI) claim MUST specify a String value that identifies the Status List Token containing the status information for the Referenced Token. The value of uri MUST be a URI conforming to [RFC3986].

        +
        • +
      +
      • +
    +
    • +
+

Application of additional restrictions and policy are at the discretion of the Relying Party.

+

The following is a non-normative example for a decoded header and payload of a Referenced Token:

+
+
+{
+  "alg": "ES256",
+  "kid": "11"
+}
+.
+{
+  "status": {
+    "status_list": {
+      "idx": 0,
+      "uri": "https://example.com/statuslists/1"
+    }
+  }
+}
+
+
+

SD-JWT-based Verifiable Credentials [SD-JWT.VC] introduce the usage of status mechanism in Section 3.2.2.2. The "status" object uses the same encoding as a JWT as defined in Section 6.2.

+

The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:

+
+
+eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
+Ikh2cktYNmZQVjB2OUtfeUNWRkJpTEZIc01heGNEXzExNEVtNlZUOHgxbGciXSwgImlz
+cyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwMDAw
+LCAiZXhwIjogMTg4MzAwMDAwMCwgInN1YiI6ICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFl
+Ny0yMTkxMjJhOWVjMmMiLCAic3RhdHVzIjogeyJzdGF0dXNfbGlzdCI6IHsiaWR4Ijog
+MCwgInVyaSI6ICJodHRwczovL2V4YW1wbGUuY29tL3N0YXR1c2xpc3RzLzEifX0sICJf
+c2RfYWxnIjogInNoYS0yNTYifQ.-kgS-R-Z4DEDlqb8kb6381_gHHNatsoF1fcVKZk3M
+06CrnV8F8k9d2w2V_YAOvgcb0f11FqDFezXBXH30d4vcw~WyIyR0xDNDJzS1F2ZUNmR2
+ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd~WyJlbHVWN
+U9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0~WyI2S
+Wo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd~
+WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ~WyJRZ19PN
+jR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTN
+EdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnU
+nJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotR
+GYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4V
+GpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0~
+
+
+

Resulting payload of the example above:

+
+
+{
+  "_sd": [
+    "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
+  ],
+  "iss": "https://example.com/issuer",
+  "iat": 1683000000,
+  "exp": 1883000000,
+  "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
+  "status": {
+    "status_list": {
+      "idx": 0,
+      "uri": "https://example.com/statuslists/1"
+    }
+  },
+  "_sd_alg": "sha-256"
+}
+
+
+
+
+
+
+

+6.3. Referenced Token in COSE +

+

The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" object according to [RFC8392] or other formats based on COSE.

+

The following content applies to the CWT Claims Set:

+
    +
  • +

    65535 (status): REQUIRED. The status claim is encoded as a Status CBOR structure and MUST include at least one data item that refers to a status mechanism. Each data item in the Status CBOR structure comprises a key-value pair, where the key must be a CBOR text string (Major Type 3) specifying the identifier of the status mechanism, and the corresponding value defines its contents. This specification defines the following data items:

    +
      +
    • +

      status_list (status list): REQUIRED when the status mechanism defined in this specification is used. It has the same definition as the status_list claim in Section 6.2 but MUST be encoded as a StatusListInfo CBOR structure with the following fields:

      +
        +
      • +

        idx: REQUIRED. Unsigned integer (Major Type 0) The idx (index) claim MUST specify an Integer that represents the index to check for status information in the Status List for the current Referenced Token. The value of idx MUST be a non-negative number, containing a value of zero or greater.

        +
        • +
      • +

        uri: REQUIRED. Text string (Major Type 3). The uri (URI) claim MUST specify a String value that identifies the Status List Token containing the status information for the Referenced Token. The value of uri MUST be a URI conforming to [RFC3986].

        +
        • +
      +
      • +
    +
    • +
+

Application of additional restrictions and policy are at the discretion of the Relying Party.

+

The following is a non-normative example of a Referenced Token in CWT format in Hex:

+
+
+d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861
+6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69
+7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f
+7374617475736c697374732f315840f0c1b76da95815a3416827480a8d52e1437f51
+96ddaf36c527ff6e2db99d0fa7f9aa57804a150733513032a85ba8f2de81c570bd43
+bd67f8512ec6a52c23e410
+
+
+

The following is the CBOR Annotated Hex output of the example above:

+
+
+d2                              # tag(18)
+  84                            #   array(4)
+    43                          #     bytes(3)
+      a10126                    #       "¡\x01&"
+    a1                          #     map(1)
+      04                        #       uint(4)
+      42                        #       bytes(2)
+        3132                    #         "12"
+    58 66                       #     bytes(102)
+      a50265313233343501736874  #       "¥\x02e12345\x01sht"
+      7470733a2f2f6578616d706c  #       "tps://exampl"
+      652e636f6d061a648c5bea04  #       "e.com\x06\x1ad\x8c[ê\x04"
+      1a8898dfea19ffffa16b7374  #       "\x1a\x88\x98ßê\x19ÿÿ¡kst"
+      617475735f6c697374a26369  #       "atus_list¢ci"
+      647800637572697821687474  #       "dx\x00curix!htt"
+      70733a2f2f6578616d706c65  #       "ps://example"
+      2e636f6d2f7374617475736c  #       ".com/statusl"
+      697374732f31              #       "ists/1"
+    58 40                       #     bytes(64)
+      f0c1b76da95815a341682748  #       "ðÁ·m©X\x15£Ah'H"
+      0a8d52e1437f5196ddaf36c5  #       "\x0a\x8dRáC\x7fQ\x96ݯ6Å"
+      27ff6e2db99d0fa7f9aa5780  #       "'ÿn-¹\x9d\x0f§ùªW\x80"
+      4a150733513032a85ba8f2de  #       "J\x15\x073Q02¨[¨òÞ"
+      81c570bd43bd67f8512ec6a5  #       "\x81Åp½C½gøQ.Æ¥"
+      2c23e410                  #       ",#ä\x10"
+
+
+

ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by introducing the status parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2. The status parameter uses the same encoding as a CWT as defined in Section 6.3.

+

It is RECOMMENDED to use status for the label of the field that contains the Status CBOR structure.

+

Application of additional restrictions and policy are at the discretion of the Relying Party.

+

The following is a non-normative example for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex:

+
+
+8443a10126a118215901f3308201ef30820195a00302010202140bfec7da97e048e
+15ac3dacb9eafe82e64fd07f5300a06082a8648ce3d040302302331143012060355
+04030c0b75746f7069612069616361310b3009060355040613025553301e170d323
+4313030313030303030305a170d3235313030313030303030305a30213112301006
+035504030c0975746f706961206473310b300906035504061302555330593013060
+72a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d9648c5a72a9
+a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d3a539f4d5883
+65e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a5301c0603551d1f0415
+30133011a00fa00d820b6578616d706c652e636f6d301e0603551d1204173015811
+36578616d706c65406578616d706c652e636f6d301d0603551d0e0416041414e290
+17a6c35621ffc7a686b7b72db06cd12351301f0603551d2304183016801454fa238
+3a04c28e0d930792261c80c4881d2c00b300e0603551d0f0101ff04040302078030
+150603551d250101ff040b3009060728818c5d050102300a06082a8648ce3d04030
+20348003045022100b7103fd4b90529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f
+9fa1f5c2e5aa0a0220070b2822ec7ce6c56804923a85b2cfbffd054cf9a915f070c
+fef7179a4bc6569590320d81859031ba766737461747573a16b7374617475735f6c
+697374a26369647819019c63757269782168747470733a2f2f6578616d706c652e6
+36f6d2f7374617475736c697374732f3167646f6354797065756f72672e69736f2e
+31383031332e352e312e6d444c6776657273696f6e63312e306c76616c696469747
+9496e666fa3667369676e6564c074323032342d31302d30315431333a33303a3032
+5a6976616c696446726f6dc074323032342d31302d30315431333a33303a30325a6
+a76616c6964556e74696cc074323032352d31302d30315431333a33303a30325a6c
+76616c756544696765737473a1716f72672e69736f2e31383031332e352e31ac005
+820a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c923da7a6f243
+01582048701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3efe98069
+0a4025820d11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b110985329
+2a8f62035820a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc99
+41095fb7a045820ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c62
+6e94457b7d8b055820bacddb4142b3842bd555206eb5acb27ded063294995c7e7fe
+fbf93ece522604d065820bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab6
+9eb9311650a48d325307582027dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c
+5b7544fb809e02ccb3e6a0858200dbd7ccc9c7727d3d17295f1b6f1914071670ee2
+3d4d33530c31f1f406b8e3b7095820a5beb5efadf37f21637209abc519830681cc5
+1f334818a823fec13b29552f5ba0a5820d8047c95f9272d7d07b2c13a9f5ac2ee02
+380ab272a165e569391d89a2152c3c0b582004939930ffb4911ef03487a153605a3
+0368b69f2437d6d21b4c90f92bc144c3e6d6465766963654b6579496e666fa16964
+65766963654b6579a40102200121582096313d6c63e24e3372742bfdb1a33ba2c89
+7dcd68ab8c753e4fbd48dca6b7f9a2258201fb3269edd418857de1b39a4e4a44b92
+fa484caa722c228288f01d0c03a2c3d66f646967657374416c676f726974686d675
+348412d3235365840b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a
+85ed800ba7acb59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50
+fe8a1c4cafe
+
+
+

The following is the CBOR Diagnostic Notation of the example above:

+
+
+[
+  << {
+    1: -7
+  } >>,
+  {
+    33: h'308201ef30820195a00302010202140bfec7da97e048e15ac3dacb9ea
+    fe82e64fd07f5300a06082a8648ce3d04030230233114301206035504030c0b
+    75746f7069612069616361310b3009060355040613025553301e170d3234313
+    030313030303030305a170d3235313030313030303030305a30213112301006
+    035504030c0975746f706961206473310b30090603550406130255533059301
+    306072a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d964
+    8c5a72a9a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d
+    3a539f4d588365e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a530
+    1c0603551d1f041530133011a00fa00d820b6578616d706c652e636f6d301e0
+    603551d120417301581136578616d706c65406578616d706c652e636f6d301d
+    0603551d0e0416041414e29017a6c35621ffc7a686b7b72db06cd12351301f0
+    603551d2304183016801454fa2383a04c28e0d930792261c80c4881d2c00b30
+    0e0603551d0f0101ff04040302078030150603551d250101ff040b300906072
+    8818c5d050102300a06082a8648ce3d0403020348003045022100b7103fd4b9
+    0529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f9fa1f5c2e5aa0a0220070b2
+    822ec7ce6c56804923a85b2cfbffd054cf9a915f070cfef7179a4bc6569'
+  },
+  << 24( << {
+    "status": {
+      "status_list": {
+        "idx": 412,
+        "uri": "https://example.com/statuslists/1"
+      }
+    },
+    "docType": "org.iso.18013.5.1.mDL",
+    "version": "1.0",
+    "validityInfo": {
+      "signed": 2024-10-01 13:30:02+00:00,
+      "validFrom": 2024-10-01 13:30:02+00:00,
+      "validUntil": 2025-10-01 13:30:02+00:00
+    },
+    "valueDigests": {
+      "org.iso.18013.5.1": {
+        0: h'a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c92
+        3da7a6f243',
+        1: h'48701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3e
+        fe980690a4',
+        2: h'd11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b11098
+        53292a8f62',
+        3: h'a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc9
+        941095fb7a',
+        4: h'ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c626e
+        94457b7d8b',
+        5: h'bacddb4142b3842bd555206eb5acb27ded063294995c7e7fefbf93
+        ece522604d',
+        6: h'bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab69eb93116
+        50a48d3253',
+        7: h'27dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c5b7544fb809
+        e02ccb3e6a',
+        8: h'0dbd7ccc9c7727d3d17295f1b6f1914071670ee23d4d33530c31f1
+        f406b8e3b7',
+        9: h'a5beb5efadf37f21637209abc519830681cc51f334818a823fec13
+        b29552f5ba',
+        10: h'd8047c95f9272d7d07b2c13a9f5ac2ee02380ab272a165e569391
+        d89a2152c3c',
+        11: h'04939930ffb4911ef03487a153605a30368b69f2437d6d21b4c90
+        f92bc144c3e'
+      }
+    },
+    "deviceKeyInfo": {
+      "deviceKey": {
+        1: 2,
+        -1: 1,
+        -2: h'96313d6c63e24e3372742bfdb1a33ba2c897dcd68ab8c753e4fbd
+        48dca6b7f9a',
+        -3: h'1fb3269edd418857de1b39a4e4a44b92fa484caa722c228288f01
+        d0c03a2c3d6'
+      }
+    },
+    "digestAlgorithm": "SHA-256"
+  } >> ) >>,
+  h'b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a85ed800ba7acb
+  59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50fe8a1c4cafe'
+]
+
+
+
+
+
+
+
+
+

+7. Status Types +

+

This document defines statuses of Referenced Tokens as Status Type values. A status describes the state, mode, condition or stage of an entity that is represented by the Referenced Token.

+

A Status List can not represent multiple statuses per Referenced Token. If the Status List contains more than one bit per token (as defined by bits in the Status List), then the whole value of bits MUST describe one value. Status Types MUST have a numeric value between 0 and 255 for their representation in the Status List. The issuer of the Status List MUST choose an adequate bits (bit size) to be able to describe the required Status Types for its application.

+
+
+

+7.1. Status Types Values +

+

This document creates a registry in Section 14.5 that includes the most common Status Type values. Additional values may defined for particular use cases. Status Types described by this document comprise:

+
    +
  • +

    0x00 - "VALID" - The status of the Referenced Token is valid, correct or legal.

    +
    • +
  • +

    0x01 - "INVALID" - The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled.

    +
    • +
  • +

    0x02 - "SUSPENDED" - The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege. This state is reversible.

    +
    • +
  • +

    0x03 - "APPLICATION_SPECIFIC_3" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
  • +

    0x0E - "APPLICATION_SPECIFIC_14" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
  • +

    0x0F - "APPLICATION_SPECIFIC_15" - The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
+

The Status Issuer MUST choose an adequate bits (bit size) to be able to describe the required Status Types for the application.

+

The processing rules for JWT or CWT precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired.

+
+
+
+
+
+
+

+8. Verification and Processing +

+
+
+

+8.1. Status List Request +

+

To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token.

+

The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) [CORS] and/or other methods as appropriate to enable Browser-Based clients to access it.

+

The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:

+
    +
  • +

    "application/statuslist+jwt" for Status List Token in JWT format

    +
    • +
  • +

    "application/statuslist+cwt" for Status List Token in CWT format

    +
    • +
+

If the Relying Party does not send an Accept Header, the response type is assumed to be known implicit or out-of-band.

+

The following are non-normative examples for a request and response for a Status List Token with type application/statuslist+jwt:

+
+
+GET /statuslists/1 HTTP/1.1
+Host: example.com
+Accept: application/statuslist+jwt
+
+
+
+
+HTTP/1.1 200 OK
+Content-Type: application/statuslist+jwt
+
+eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e
+yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
+GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
+WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
+nR0bCI6NDMyMDB9.pSUxmCdwv3_JuXxXkM3uZhG8wp2Fmkzrl8Kwf2UHCG8xDx5HuReH
+seQkLdJIa5LUPIbgfY4x7SrZwRDMO8TC9g
+
+
+
+
+
+
+

+8.2. Status List Response +

+

In the successful response, the Status Provider MUST use the following content-type:

+
    +
  • +

    "application/statuslist+jwt" for Status List Token in JWT format

    +
    • +
  • +

    "application/statuslist+cwt" for Status List Token in CWT format

    +
    • +
+

In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of Section 5.1. +In the case of "application/statuslist+cwt", the response MUST be of type CWT and follow the rules of Section 5.2.

+

The HTTP response SHOULD use gzip Content-Encoding as defined in [RFC9110].

+
+
+
+
+

+8.3. Validation Rules +

+

Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected attributes, valid signature, expiration time. The processing rules for JWT or CWT precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired. As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token.

+

If this validation was not successful, the Referenced Token MUST be rejected. If the validation was successful, the Relying Party MUST perform the following validation steps to evaluate the status of the reference token:

+
    +
  1. +

    Check for the existence of a status claim, check for the existence of a status_list claim within the status claim and validate that the content of status_list adheres to the rules defined in Section 6.2 for JWTs and Section 6.3 for CWTs. This step can be overruled if defined within the Referenced Token Format natively

    +
    2. +
  2. +

    Resolve the Status List Token from the provided URI

    +
    3. +
  3. +

    Validate the Status List Token:

    +
      +
    1. +

      Validate the Status List Token by following the rules defined in section 7.2 of [RFC7519] for JWTs and section 7.2 of [RFC8392] for CWTs

      +
      2. +
    2. +

      Check for the existence of the required claims as defined in Section 5.1 and Section 5.2 depending on token type

      +
      3. +
    +
    4. +
  4. +

    All existing claims in the Status List Token MUST be checked according to the rules in Section 5.1 and Section 5.2

    +
      +
    1. +

      The subject claim (sub or 2) of the Status List Token MUST be equal to the uri claim in the status_list object of the Referenced Token

      +
      2. +
    2. +

      If the Relying Party has custom policies regarding the freshness of the Status List Token, it SHOULD check the issued at claim (iat or 6)

      +
      3. +
    3. +

      If expiration time is defined (exp or 4), it MUST be checked if the Status List Token is expired

      +
      4. +
    4. +

      If the Relying Party is using a system for caching the Status List Token, it SHOULD check the ttl claim of the Status List Token and retrieve a fresh copy if (time status was resolved + ttl < current time)

      +
      5. +
    +
    5. +
  5. +

    Decompress the Status List with a decompressor that is compatible with DEFLATE [RFC1951] and ZLIB [RFC1950]

    +
    6. +
  6. +

    Retrieve the status value of the index specified in the Referenced Token as described in Section 4. Fail if the provided index is out of bound of the Status List

    +
    7. +
  7. +

    Check the status value as described in Section 7

    +
    8. +
+

If any of these checks fails, no statement about the status of the Referenced Token can be made and the Referenced Token SHOULD be rejected.

+
+
+
+
+

+8.4. Historical resolution +

+

By default, the status mechanism defined in this specification only conveys information about the state of Reference Tokens at the time the Status List Token was issued. The validity period for this information, as defined by the issuer, is explicitly stated by the iat (issued at) and exp (expiration time) claims for JWT, and their corresponding ones for the CWT representation. If support for historical status information is required, this can be achieved by extending the request for the Status List Token as defined in Section 8.1 with a timestamp. This feature has additional privacy implications as described in Section 12.7.

+

To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token with the additional query parameter time and its value being a unix timestamp. The response for a valid request SHOULD contain a Status List Token that was valid for that specified time or an error.

+

If the Server does not support the additional query parameter, it SHOULD return a status code of 501 (Not Implemented), or if the requested time is not supported it SHOULD return a status code of 406 (Not Acceptable). A Status List Token might be served via static file hosting (e.g., leveraging a Content Delivery Network), which would result in the client not being able to retrieve those status codes. Thus, the client MUST verify support for this feature by verifying that the requested timestamp is within the valid time of the returned token signaled via iat (6 for CWT) and exp (4 for CWT).

+

The following is a non-normative example for a GET request using the time query parameter:

+
+
+GET /statuslists/1?time=1686925000 HTTP/1.1
+Host: example.com
+Accept: application/statuslist+jwt
+
+
+

The following is a non-normative example for a response for the above Request:

+
+
+HTTP/1.1 200 OK
+Content-Type: application/statuslist+jwt
+
+eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e
+yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
+GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
+WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
+nR0bCI6NDMyMDB9.pSUxmCdwv3_JuXxXkM3uZhG8wp2Fmkzrl8Kwf2UHCG8xDx5HuReH
+seQkLdJIa5LUPIbgfY4x7SrZwRDMO8TC9g
+
+
+
+
+
+
+
+
+

+9. Status List Aggregation +

+

Status List Aggregation is an optional mechanism to retrieve a list of URIs to all Status List Tokens, allowing a Relying Party to fetch all relevant Status Lists for a specific type of Referenced Token or Issuer. This mechanism is intended to support fetching and caching mechanisms and allow offline validation of the status of a reference token for a period of time.

+

If a Relying Party encounters an invalid Status List referenced in the response from the Status List Aggregation endpoint, it SHOULD continue processing the other valid Status Lists referenced in the response.

+

There are two options for a Relying Party to retrieve the Status List Aggregation. +An Issuer MAY support any of these mechanisms:

+
    +
  • +

    Issuer metadata: The Issuer of the Referenced Token publishes an URI which links to Status List Aggregation, e.g. in publicly available metadata of an issuance protocol

    +
    • +
  • +

    Status List Parameter: The Status Issuer includes an additional claim in the Status List Token that contains the Status List Aggregation URI.

    +
    • +
+
+
+

+9.1. 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 via a VICAL extension for ISO mDoc / mDL.

+

The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.

+
+
+
+
+

+9.2. Status List Parameter +

+

The URI to the Status List Aggregation MAY be provided as the optional parameter aggregation_uri in the Status List itself as explained inSection 4.2 and Section 4.1 respectively. A Relying Party may use this URI to retrieve an up-to-date list of relevant Status Lists.

+
+
+
+
+

+9.3. Status List Aggregation in JSON Format +

+

This section defines the structure for a JSON-encoded Status List Aggregation:

+
    +
  • +

    status_lists: REQUIRED. JSON array of strings that contains URIs linking to Status List Tokens.

    +
    • +
+

The Status List Aggregation URI provides a list of Status List URIs. This aggregation in JSON and the media type return SHOULD be application/json. A Relying Party can iterate through this list and fetch all Status List Tokens before encountering the specific URI in a Referenced Token.

+

The following is a non-normative example for media type application/json:

+
+
+{
+   "status_lists" : [
+      "https://example.com/statuslists/1",
+      "https://example.com/statuslists/2",
+      "https://example.com/statuslists/3"
+   ]
+}
+
+
+
+
+
+
+
+
+

+10. Further Examples +

+
+
+

+10.1. Status List with 2-Bit Status Values in JSON format +

+

In this example, the Status List additionally includes the Status Type "SUSPENDED". As the Status Type value for "SUSPENDED" is 0x02 and does not fit into 1 bit, the "bits" is required to be 2.

+

This example Status List represents the status of 12 Referenced Tokens, requiring 24 bits (3 bytes) of status.

+
+
+status[0] = 1
+status[1] = 2
+status[2] = 0
+status[3] = 3
+status[4] = 0
+status[5] = 1
+status[6] = 0
+status[7] = 1
+status[8] = 1
+status[9] = 2
+status[10] = 3
+status[11] = 3
+
+
+

These bits are concatenated:

+
+
+byte             0                  1                  2
+bit       7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0
+         +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
+values   |1|1|0|0|1|0|0|1|  |0|1|0|0|0|1|0|0|  |1|1|1|1|1|0|0|1|
+         +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
+          \ / \ / \ / \ /    \ / \ / \ / \ /    \ / \ / \ / \ /
+status     3   0   2   1      1   0   1   0      3   3   2   1
+index      3   2   1   0      7   6   5   4      11  10  9   8
+           \___________/      \___________/      \___________/
+                0xC9               0x44               0xF9
+
+
+
+

Resulting in the byte array and compressed/base64url-encoded Status List:

+
+
+byte_array = [0xc9, 0x44, 0xf9]
+encoded:
+{
+  "bits": 2,
+  "lst": "eNo76fITAAPfAgc"
+}
+
+
+
+
+
+
+
+
+

+11. Security Considerations +

+
+
+

+11.1. Correct decoding and parsing of the encoded Status List +

+

Implementers should be particularly careful for the correct parsing and decoding of the Status List. Incorrect implementations might check the index on the wrong data or miscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least significant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to write). Endianness does not apply here because each status value fits within a single byte.

+

Implementations are RECOMMENDED to verify correctness using the test vectors given by this specification.

+
+
+
+
+

+11.2. Security Guidance for JWT and CWT +

+

A Status List Token in the JWT format should follow the security considerations of [RFC7519] and the best current practices of [RFC8725].

+

A Status List Token in the CWT format should follow the security considerations of [RFC8392].

+
+
+
+
+

+11.3. Cached and Stale Status Lists +

+

When Relying Parties fetch the Status List, they need to be aware of its up-to-date status. The 'ttl' (time-to-live) claim +in the Status List Token provides one mechanism for setting a maximum cache time for the fetched data. This property permits distribution of +a Status List to a CDN or other distribution mechanism while giving guidance to consumers of the Status List on how often they need to fetch +a fresh copy of the Status List even if that Status List is not expired.

+
+
+
+
+
+
+

+12. Privacy Considerations +

+
+
+

+12.1. Observability of Issuers +

+

The main privacy consideration for a Status List, especially in the context of the Issuer-Holder-Verifier model [SD-JWT.VC], is to prevent the Issuer from tracking the usage of the Referenced Token when the status is being checked. If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the issued token by correlating the date and identity of Relying Parties, that are requesting the status.

+

The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the Relying Party is requesting the Status List. The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy. This limits the possibilities of tracking by the Issuer.

+

The herd privacy is depending on the number of entities within the Status List called its size. A larger size results in better privacy but also impacts the performance as more data has to be transferred to read the Status List.

+

Additionally, the Issuer may analyse data from the HTTP request to identify the Relying Party, e.g. through the sender's IP address.

+

This behaviour may be mitigated by:

+
    +
  • +

    private relay protocols or other mechanism hiding the original sender like [RFC9458].

    +
    • +
  • +

    using trusted Third Party Hosting, see Section 12.6.

    +
    • +
+
+
+
+
+

+12.2. Malicious Issuers +

+

A malicious Issuer could bypass the privacy benefits of the herd privacy by generating a unique Status List for every Referenced Token. By these means, he could maintain a mapping between Referenced Tokens and Status Lists and thus track the usage of Referenced Tokens by utilizing this mapping for the incoming requests. This malicious behaviour could be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes.

+
+
+
+
+

+12.3. Observability of Relying Parties +

+

Once the Relying Party receives the Referenced Token, this enables him to request the Status List to validate its status through the provided uri parameter and look up the corresponding index. However, the Relying Party may persistently store the uri and index of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for a KYC process that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential.

+

This behaviour could be mitigated by:

+
    +
  • +

    regular re-issuance of the Referenced Token, see Section 13.1.

    +
    • +
+
+
+
+
+

+12.4. Observability of Outsiders +

+

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 Section 8.4

    +
    • +
  • +

    disable the Status List Aggregation Section 9

    +
    • +
  • +

    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

    +
    • +
+
+
+
+
+

+12.5. Unlinkability +

+

Colluding Issuers and Relying Parties have the possibility to link two transactions, as the tuple of uri and index inside the Referenced Token are unique and therefore traceable data. By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties. It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties.

+

To avoid privacy risks for colluding Relying Parties, it is RECOMMENDED that Issuers use batch issuance to issue multiple tokens, see Section 13.1.

+

To avoid further correlatable information by the values of uri and index, Issuers are RECOMMENDED to:

+
    +
  • +

    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

    +
    • +
+
+
+
+
+

+12.6. Third Party Hosting +

+

If the roles of the Issuer and the Status Provider are performed by two different entities, this may give additional privacy assurances as the Issuer has no means to identify the Relying Party or its request.

+

Third Party hosting may also allow for greater scalability, as the Status List Tokens may be served by operators with greater resources, like CDNs.

+
+
+
+
+

+12.7. Historical Resolution +

+

By default, this specification only supports providing Status List information for the most recent status information and does not allow the lookup of historical information like a validity state at a specific point in time. There exists optional support for a query parameter that allows these kind of historic lookups as described in Section 8.4. There are scenarios where such a functionality is necessary, but this feature should only be implemented when the scenario and the consequences of enabling historical resolution are fully understood.

+

There are strong privacy concerns that have to be carefully taken into considerations when providing a mechanism that allows historic requests for status information - see Section 12.3 for more details. Support for this functionality is optional and Implementers are RECOMMENDED to not support historic requests unless there are strong reasons to do so and after carefully considering the privacy implications.

+
+
+
+
+
+
+

+13. Implementation Considerations +

+
+
+

+13.1. Token Lifecycle +

+

The lifetime of a Status List Token depends on the lifetime of its Referenced Tokens. Once all Referenced Tokens are expired, the Issuer may stop serving the Status List Token.

+

Referenced Tokens may be regularly re-issued to mitigate linkability of presentations to Relying Parties. In this case, every re-issued Referenced Token MUST have a fresh Status List entry in order to prevent this becoming possible source of correlation.

+

Referenced Tokens may also be issued in batches, such that Holders can use individual tokens for every transaction. In this case, every Referenced Token MUST have a dedicated Status List entry. Revoking batch issued Referenced Tokens might reveal this correlation later on.

+
+
+
+
+

+13.2. Default Values and Double Allocation +

+

Implementations producing Status Lists are RECOMMENDED to initialize the Status List byte array with a default value and provide this as an initialization parameter to the Issuer. The Issuer is RECOMMENDED to use a default value that represents the most common value for its Referenced Tokens to avoid an update during issuance.

+

Implementations producing Status Lists are RECOMMENDED to prevent double allocation, i.e. re-using the same uri and index for multiple Referenced Tokens. The Issuer MUST prevent any unintended double allocation by using the Status List.

+
+
+
+
+

+13.3. Status List Size +

+

The Status List Issuer may increase the size of a Status List if it requires indices for additional Referenced Tokens. It is RECOMMENDED that the size of a Status List in bits is divisible in bytes (8 bits) without a remainder, i.e. size-in-bits % 8 = 0.

+

The Status List Issuer may chunk its Referenced Tokens into multiple Status Lists to reduce the transmission size of an individual Status List Token. This may be useful for setups where some entities operate in constrained environments, e.g. for mobile internet or embedded devices.

+
+
+
+
+

+13.4. Status List Formats +

+

This specification defines 2 different token formats of the Status List:

+
    +
  • +

    JWT

    +
    • +
  • +

    CWT

    +
    • +
+

This specification states no requirements to not mix different formats like a CBOR based Referenced Token using a JWT for the Status List, but the expectation is that within an ecosystem, a choice for specific formats is made. +Within such an ecosystem, only support for those selected variants is required and implementations should know what to expect via a profile.

+
+
+
+
+
+
+

+14. IANA Considerations +

+
+
+

+14.1. JSON Web Token Claims Registration +

+

This specification requests registration of the following Claims in the +IANA "JSON Web Token Claims" registry [IANA.JWT] established by [RFC7519].

+
+
+

+14.1.1. Registry Contents +

+
    +
  • +

    Claim Name: status

    +
    • +
  • +

    Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the JWT.

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 6.1 of this specification

    +
    • +
+


+
    +
  • +

    Claim Name: status_list

    +
    • +
  • +

    Claim Description: A status list containing up-to-date status information on multiple tokens.

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 5.1 of this specification

    +
    • +
+


+
    +
  • +

    Claim Name: ttl

    +
    • +
  • +

    Claim Description: Time to Live

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 5.1 of this specification

    +
    • +
+
+
+
+
+
+
+

+14.2. JWT Status Mechanism Methods Registry +

+

This specification establishes the IANA "Status Mechanism Methods" registry for JWT "status" member values. The registry records the status mechanism method member and a reference to the specification that defines it.

+
+
+

+14.2.1. Registration Template +

+

Status Method Value:

+
    +
  • +

    The name requested (e.g., "status_list"). The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

    +
    • +
+

Status Method Description:

+
    +
  • +

    Brief description of the status mechanism method.

    +
    • +
+

Change Controller:

+
    +
  • +

    For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

    +
    • +
+

Specification Document(s):

+
    +
  • +

    Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

    +
    • +
+
+
+
+
+

+14.2.2. Initial Registry Contents +

+
    +
  • +

    Status Method Value: status_list

    +
    • +
  • +

    Status Method Description: A status list containing up-to-date status information on multiple tokens.

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 6.2 of this specification

    +
    • +
+
+
+
+
+
+
+

+14.3. CBOR Web Token Claims Registration +

+

This specification requests registration of the following Claims in the +IANA "CBOR Web Token (CWT) Claims" registry [IANA.CWT] established by [RFC8392].

+
+
+

+14.3.1. Registry Contents +

+


+
    +
  • +

    Claim Name: status

    +
    • +
  • +

    Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.

    +
    • +
  • +

    JWT Claim Name: status

    +
    • +
  • +

    Claim Key: TBD (requested assignment 65535)

    +
    • +
  • +

    Claim Value Type: map

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Reference: Section 6.1 of this specification

    +
    • +
+


+
    +
  • +

    Claim Name: status_list

    +
    • +
  • +

    Claim Description: A status list containing up-to-date status information on multiple tokens.

    +
    • +
  • +

    JWT Claim Name: status_list

    +
    • +
  • +

    Claim Key: TBD (requested assignment 65533)

    +
    • +
  • +

    Claim Value Type: map

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 5.2 of this specification

    +
    • +
+


+
    +
  • +

    Claim Name: ttl

    +
    • +
  • +

    Claim Description: Time to Live

    +
    • +
  • +

    JWT Claim Name: ttl

    +
    • +
  • +

    Claim Key: TBD (requested assignment 65534)

    +
    • +
  • +

    Claim Value Type: unsigned integer

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 5.2 of this specification

    +
    • +
+
+
+
+
+
+
+

+14.4. CWT Status Mechanism Methods Registry +

+

This specification establishes the IANA "Status Mechanism Methods" registry for CWT "status" member values. The registry records the status mechanism method member and a reference to the specification that defines it.

+
+
+

+14.4.1. Registration Template +

+

Status Method Value:

+
    +
  • +

    The name requested (e.g., "status_list"). The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

    +
    • +
+

Status Method Description:

+
    +
  • +

    Brief description of the status mechanism method.

    +
    • +
+

Change Controller:

+
    +
  • +

    For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

    +
    • +
+

Specification Document(s):

+
    +
  • +

    Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

    +
    • +
+
+
+
+
+

+14.4.2. Initial Registry Contents +

+
    +
  • +

    Status Method Value: status_list

    +
    • +
  • +

    Status Method Description: A status list containing up-to-date status information on multiple tokens.

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 6.3 of this specification

    +
    • +
+
+
+
+
+
+
+

+14.5. Status Types Registry +

+

This specification establishes the IANA "Status Types" registry for Status List values. The registry records the a human readable label, the bit representation and a common description for it.

+
+
+

+14.5.1. Registration Template +

+

Status Type Name:

+
    +
  • +

    The name is a human-readable case insensitive label for the Status Type that helps to talk about a Status of Referenced Token in common language.

    +
    • +
+

Status Type Description:

+
    +
  • +

    Brief description of the Status Type and optional examples.

    +
    • +
+

Status Type value:

+
    +
  • +

    The bit representation of the Status Type in a byte hex representation. Values are filled up with zeros if they have less than 8 bits.

    +
    • +
+

Change Controller:

+
    +
  • +

    For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

    +
    • +
+

Specification Document(s):

+
    +
  • +

    Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

    +
    • +
+
+
+
+
+

+14.5.2. Initial Registry Contents +

+
    +
  • +

    Status Type Name: VALID

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is valid, correct or legal.

    +
    • +
  • +

    Status Type value: 0x00

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 7 of this specification

    +
    • +
+


+
    +
  • +

    Status Type Name: INVALID

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled.

    +
    • +
  • +

    Status Type value: 0x01

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 7 of this specification

    +
    • +
+


+
    +
  • +

    Status Type Name: SUSPENDED

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege. This state is reversible.

    +
    • +
  • +

    Status Type value: 0x02

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 7 of this specification

    +
    • +
+


+
    +
  • +

    Status Type Name: APPLICATION_SPECIFIC_3

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
  • +

    Status Type value: 0x03

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 7 of this specification

    +
    • +
+


+
    +
  • +

    Status Type Name: APPLICATION_SPECIFIC_14

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
  • +

    Status Type value: 0x0E

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 7 of this specification

    +
    • +
+


+
    +
  • +

    Status Type Name: APPLICATION_SPECIFIC_15

    +
    • +
  • +

    Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band.

    +
    • +
  • +

    Status Type value: 0x0F

    +
    • +
  • +

    Change Controller: IETF

    +
    • +
  • +

    Specification Document(s): Section 6.2 of this specification

    +
    • +
+


+
+
+
+
+
+
+

+14.6. Media Type Registration +

+

This section requests registration of the following media types [RFC2046] in +the "Media Types" registry [IANA.MediaTypes] in the manner described +in [RFC6838].

+

To indicate that the content is an JWT-based Status List:

+
    +
  • +

    Type name: application

    +
    • +
  • +

    Subtype name: statuslist+jwt

    +
    • +
  • +

    Required parameters: n/a

    +
    • +
  • +

    Optional parameters: n/a

    +
    • +
  • +

    Encoding considerations: See Section 5.1 of this specification

    +
    • +
  • +

    Security considerations: See Section 11 of this specification

    +
    • +
  • +

    Interoperability considerations: n/a

    +
    • +
  • +

    Published specification: this specification

    +
    • +
  • +

    Applications that use this media type: Applications using this specification for updated status information of tokens

    +
    • +
  • +

    Fragment identifier considerations: n/a

    +
    • +
  • +

    Additional information: n/a

    +
    • +
  • +

    Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

    +
    • +
  • +

    Intended usage: COMMON

    +
    • +
  • +

    Restrictions on usage: none

    +
    • +
  • +

    Author: Paul Bastian, paul.bastian@posteo.de

    +
    • +
  • +

    Change controller: IETF

    +
    • +
  • +

    Provisional registration? No

    +
    • +
+

To indicate that the content is an CWT-based Status List:

+
    +
  • +

    Type name: application

    +
    • +
  • +

    Subtype name: statuslist+cwt

    +
    • +
  • +

    Required parameters: n/a

    +
    • +
  • +

    Optional parameters: n/a

    +
    • +
  • +

    Encoding considerations: See Section 5.2 of this specification

    +
    • +
  • +

    Security considerations: See Section 11 of this specification

    +
    • +
  • +

    Interoperability considerations: n/a

    +
    • +
  • +

    Published specification: this specification

    +
    • +
  • +

    Applications that use this media type: Applications using this specification for updated status information of tokens

    +
    • +
  • +

    Fragment identifier considerations: n/a

    +
    • +
  • +

    Additional information: n/a

    +
    • +
  • +

    Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

    +
    • +
  • +

    Intended usage: COMMON

    +
    • +
  • +

    Restrictions on usage: none

    +
    • +
  • +

    Author: Paul Bastian, paul.bastian@posteo.de

    +
    • +
  • +

    Change controller: IETF

    +
    • +
  • +

    Provisional registration? No

    +
    • +
+
+
+
+
+
+
+

+15. References +

+
+
+

+15.1. Normative References +

+
+
[CORS]
+
+WHATWG, "Fetch Living Standard", n.d., <https://fetch.spec.whatwg.org/#http-cors-protocol>.
+
+
[IANA.CWT]
+
+IANA, "CBOR Web Token (CWT) Claims", n.d., <https://www.iana.org/assignments/cwt/cwt.xhtml>.
+
+
[IANA.JOSE]
+
+IANA, "JSON Object Signing and Encryption (JOSE)", n.d., <https://www.iana.org/assignments/jose/jose.xhtml>.
+
+
[IANA.JWT]
+
+IANA, "JSON Web Token Claims", n.d., <https://www.iana.org/assignments/jwt/jwt.xhtml>.
+
+
[IANA.MediaTypes]
+
+IANA, "Media Types", n.d., <https://www.iana.org/assignments/media-types/media-types.xhtml>.
+
+
[RFC1950]
+
+Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, , <https://www.rfc-editor.org/rfc/rfc1950>.
+
+
[RFC1951]
+
+Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, , <https://www.rfc-editor.org/rfc/rfc1951>.
+
+
[RFC2046]
+
+Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, , <https://www.rfc-editor.org/rfc/rfc2046>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC3986]
+
+Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
+
+
[RFC6125]
+
+Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, , <https://www.rfc-editor.org/rfc/rfc6125>.
+
+
[RFC6838]
+
+Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/rfc/rfc6838>.
+
+
[RFC7515]
+
+Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
+
+
[RFC7519]
+
+Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC8259]
+
+Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
+
+
[RFC8392]
+
+Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
+
+
[RFC8725]
+
+Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, , <https://www.rfc-editor.org/rfc/rfc8725>.
+
+
[RFC8949]
+
+Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
+
+
[RFC9052]
+
+Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
+
+
[RFC9110]
+
+Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
+
+
[RFC9596]
+
+Jones, M.B. and O. Steele, "CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter", RFC 9596, DOI 10.17487/RFC9596, , <https://www.rfc-editor.org/rfc/rfc9596>.
+
+
+
+
+
+
+

+15.2. Informative References +

+
+
[ISO.mdoc]
+
+ISO/IEC JTC 1/SC 17, "ISO/IEC 18013-5:2021 ISO-compliant driving licence", n.d..
+
+
[RFC6749]
+
+Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
+
+
[RFC7662]
+
+Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <https://www.rfc-editor.org/rfc/rfc7662>.
+
+
[RFC7800]
+
+Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/rfc/rfc7800>.
+
+
[RFC9458]
+
+Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, , <https://www.rfc-editor.org/rfc/rfc9458>.
+
+
[SD-JWT.VC]
+
+Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-06>.
+
+
+
+
+
+
+
+
+

+Acknowledgments +

+

We would like to thank +Brian Campbell, +Filip Skokan, +Francesco Marino, +Guiseppe De Marco, +Kristina Yasuda, +Markus Kreusch, +Martijn Haring, +Michael B. Jones, +Mike Prorock, +Oliver Terbu, +Orie Steele, +Timo Glastra +and +Torsten Lodderstedt

+

for their valuable contributions, discussions and feedback to this specification.

+
+
+
+
+

+Document History +

+

-06

+
    +
  • +

    remove unsigned options (json/cbor) of status list

    +
    • +
  • +

    add section about mixing status list formats and media type

    +
    • +
  • +

    fixes from IETF review

    +
    • +
+

-05

+
    +
  • +

    add optional support for historical requests

    +
    • +
  • +

    update CBOR claim definitions

    +
    • +
  • +

    improve section on Status Types and introduce IANA registry for it

    +
    • +
  • +

    add Status Issuer and Status Provider role description to the introduction/terminology

    +
    • +
  • +

    add information on third party hosting to security consideration

    +
    • +
  • +

    remove constraint that Status List Token must not use a MAC

    +
    • +
+

-04

+
    +
  • +

    add mDL example as Referenced Token and consolidate CWT and CBOR sections

    +
    • +
  • +

    add implementation consideration for Default Values, Double Allocation and Status List Size

    +
    • +
  • +

    add privacy consideration on using private relay protocols

    +
    • +
  • +

    add privacy consideration on observability of outsiders

    +
    • +
  • +

    add security considerations on correct parsing and decoding

    +
    • +
  • +

    remove requirement for matching iss claim in Referenced Token and Status List Token

    +
    • +
  • +

    add sd-jwt-vc example

    +
    • +
  • +

    fix CWT status_list map encoding

    +
    • +
  • +

    editorial fixes

    +
    • +
  • +

    add CORS considerations to the http endpoint

    +
    • +
  • +

    fix reference of Status List in CBOR format

    +
    • +
  • +

    added status_list CWT claim key assigned

    +
    • +
  • +

    move base64url definition to terminology

    +
    • +
+

-03

+
    +
  • +

    remove unused reference to RFC9111

    +
    • +
  • +

    add validation rules for status list token

    +
    • +
  • +

    introduce the status list aggregation mechanism

    +
    • +
  • +

    relax requirements for status_list claims to contain other parameters

    +
    • +
  • +

    change cwt referenced token example to hex and annotated hex

    +
    • +
  • +

    require TLS only for fetching Status List, not for Status List Token

    +
    • +
  • +

    remove the undefined phrase Status List endpoint

    +
    • +
  • +

    remove http caching in favor of the new ttl claim

    +
    • +
  • +

    clarify the sub claim of Status List Token

    +
    • +
  • +

    relax status_list iss requirements for CWT

    +
    • +
  • +

    Fixes missing parts & iana ttl registration in CWT examples

    +
    • +
+

-02

+
    +
  • +

    add ttl claim to Status List Token to convey caching

    +
    • +
  • +

    relax requirements on referenced token

    +
    • +
  • +

    clarify Deflate / zlib compression

    +
    • +
  • +

    make a reference to the Issuer-Holder-Verifier model of SD-JWT VC

    +
    • +
  • +

    add COSE/CWT/CBOR encoding

    +
    • +
+

-01

+
    +
  • +

    Rename title of the draft

    +
    • +
  • +

    add design consideration to the introduction

    +
    • +
  • +

    Change status claim to in referenced token to allow re-use for other mechanisms

    +
    • +
  • +

    Add IANA Registry for status mechanisms

    +
    • +
  • +

    restructure the sections of this document

    +
    • +
  • +

    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

+
    +
  • +

    Initial draft after working group adoption

    +
    • +
  • +

    update acknowledgments

    +
    • +
  • +

    renamed Verifier to Relying Party

    +
    • +
  • +

    added IANA consideration

    +
    • +
+

[ draft-ietf-oauth-status-list ]

+

-01

+
    +
  • +

    Applied editorial improvements suggested by Michael Jones.

    +
    • +
+

-00

+
    +
  • +

    Initial draft

    +
    • +
+
+
+
+
+

+Authors' Addresses +

+
+
Tobias Looker
+
MATTR
+ +
+
+
Paul Bastian
+ +
+
+
Christian Bormann
+
Robert Bosch GmbH
+ +
+
+
+ + + diff --git a/tl/issue-182/draft-ietf-oauth-status-list.txt b/tl/issue-182/draft-ietf-oauth-status-list.txt new file mode 100644 index 0000000..9d1468e --- /dev/null +++ b/tl/issue-182/draft-ietf-oauth-status-list.txt @@ -0,0 +1,2184 @@ + + + + +Network Working Group T. Looker +Internet-Draft MATTR +Intended status: Informational P. Bastian +Expires: 2 June 2025 + C. Bormann + Robert Bosch GmbH + 29 November 2024 + + + Token Status List + draft-ietf-oauth-status-list-latest + +Abstract + + This specification defines status list data structures and processing + rules for representing the status of tokens secured by JSON Object + Signing and Encryption (JOSE) or CBOR Object Signing and + Encryption(COSE), such as JSON Web Tokens (JWTs), CBOR Web Tokens + (CWTs) and ISO mdoc. Status Lists are provided in the form of JWTs + or CWTs. + +About This Document + + This note is to be removed before publishing as an RFC. + + The latest revision of this draft can be found at https://oauth- + wg.github.io/draft-ietf-oauth-status-list/draft-ietf-oauth-status- + list.html. Status information for this document may be found at + https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/. + + Source for this draft and an issue tracker can be found at + https://github.com/oauth-wg/draft-ietf-oauth-status-list. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 2 June 2025. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Rationale + 1.2. Design Considerations + 2. Conventions and Definitions + 3. Terminology + 4. Status List + 4.1. Status List in JSON Format + 4.2. Status List in CBOR Format + 5. Status List Token + 5.1. Status List Token in JWT Format + 5.2. Status List Token in CWT Format + 6. Referenced Token + 6.1. Status Claim + 6.2. Referenced Token in JOSE + 6.3. Referenced Token in COSE + 7. Status Types + 7.1. Status Types Values + 8. Verification and Processing + 8.1. Status List Request + 8.2. Status List Response + 8.3. Validation Rules + 8.4. Historical resolution + 9. Status List Aggregation + 9.1. Issuer Metadata + 9.2. Status List Parameter + 9.3. Status List Aggregation in JSON Format + 10. Further Examples + 10.1. Status List with 2-Bit Status Values in JSON format + 11. Security Considerations + 11.1. Correct decoding and parsing of the encoded Status List + 11.2. Security Guidance for JWT and CWT + 11.3. Cached and Stale Status Lists + 12. Privacy Considerations + 12.1. Observability of Issuers + 12.2. Malicious Issuers + 12.3. Observability of Relying Parties + 12.4. Observability of Outsiders + 12.5. Unlinkability + 12.6. Third Party Hosting + 12.7. Historical Resolution + 13. Implementation Considerations + 13.1. Token Lifecycle + 13.2. Default Values and Double Allocation + 13.3. Status List Size + 13.4. Status List Formats + 14. IANA Considerations + 14.1. JSON Web Token Claims Registration + 14.1.1. Registry Contents + 14.2. JWT Status Mechanism Methods Registry + 14.2.1. Registration Template + 14.2.2. Initial Registry Contents + 14.3. CBOR Web Token Claims Registration + 14.3.1. Registry Contents + 14.4. CWT Status Mechanism Methods Registry + 14.4.1. Registration Template + 14.4.2. Initial Registry Contents + 14.5. Status Types Registry + 14.5.1. Registration Template + 14.5.2. Initial Registry Contents + 14.6. Media Type Registration + 15. References + 15.1. Normative References + 15.2. Informative References + Acknowledgments + Document History + Authors' Addresses + +1. Introduction + + Token formats secured by JOSE [IANA.JOSE] or COSE [RFC9052], such as + JSON Web Tokens (JWTs) [RFC7519], CBOR Web Tokens (CWTs) [RFC8392] + and ISO mdoc [ISO.mdoc], 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 JWT + and CWT formats that describe the individual statuses of multiple + Referenced Tokens, which themselves are most commonly data structures + secured by JOSE or COSE. 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 is + provided within a Status List Token protected by cryptographic + signature or MAC and this document defines its representations in JWT + and CWT format. 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 [SD-JWT.VC]. The + following diagram depicts the relationship between the involved roles + (Relying Party is equivalent to Verifier of [SD-JWT.VC]): + + issue present + Referenced Referenced + ┌────────┐ Token ┌────────┐ Token ┌───────────────┐ + │ Issuer ├───────────►│ Holder ├───────────►│ Relying Party │ + └─┬──────┘ └────────┘ └──┬────────────┘ + ▼ update status │ + ┌───────────────┐ │ + │ Status Issuer │ │ + └─┬─────────────┘ │ + ▼ provide Status List │ + ┌─────────────────┐ fetch Status List │ + │ Status Provider │◄───────────────────────────┘ + └─────────────────┘ + + An Issuer issues Referenced Tokens to a Holder, the Holder uses and + presents those Referenced Tokens to a Relying Party. The Issuer + gives updated status information to the Status Issuer, who creates a + Status List Token. The Status Issuer provides the Status List Token + to the Status Provider, who serves the Status List Token on a public, + resolvable endpoint. The roles of the Issuer (of the Referenced + Token), the Status Issuer and the Status Provider may be fulfilled by + the same entity. If not further specified, the term Issuer may refer + to an entity acting for all three roles. + + The following diagram depicts the relationship between the artifacts: + + ┌────────────────┐ describes status ┌──────────────────┐ + │ Status List ├──────────────────►│ Referenced Token │ + │ (JSON or CBOR) │◄──────────────────┤ (JOSE or COSE) │ + └─────┬──────────┘ references └──────────────────┘ + │ + │ embedded in + ▼ + ┌───────────────────┐ + │ Status List Token │ + │ (JWT or CWT) │ + └───────────────────┘ + + The Referenced Token is referenced by the Status List, which + described the status of the Referenced Token. The Status List is + embedded and secured within a Status List Token. + +1.1. Rationale + + 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 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 Status Provider. + + This specification establishes the IANA "Status Mechanism Methods" + registry for status mechanism and registers the members defined by + this specification. Other specifications can register other members + used for status retrieval. + +1.2. 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 unnecessary 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 + + * the specification shall not specify key resolution or trust + frameworks + + * the specification shall design an extension point to convey + information about the status of a token that can be re-used by + other mechanisms + +2. Conventions and Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Terminology + + Issuer: An entity that issues the Referenced Token. + + Status Issuer: An entity that issues the Status List Token about the + status information of the Referenced Token. This role may be + fulfilled by the Issuer. + + Status Provider: An entity that provides the Status List Token on a + public endpoint. This role may be fulfilled by the Status Issuer. + + Holder: An entity that receives Referenced Tokens form the Issuer + and presents them to Relying Parties. + + Relying Party: An entity that relies on the Status List Token to + validate the status of the Referenced Token. Also known as + Verifier. + + Status List: An object in JSON or CBOR representation containing a + bit array that lists the statuses of many Referenced Tokens. + + Status List Token: A token in JWT or CWT representation that + contains a cryptographically secured Status List. + + Referenced Token: A cryptographically secured data structure which + contains a reference to a Status List Token. It is RECOMMENDED to + use JSON [RFC8259] with JOSE as defined in [RFC7515] or CBOR + [RFC8949] with COSE as defined in [RFC9052]. The information from + the contained Status List gives the Relying Party additional + information about the current status of the Referenced Token. + Examples for Referenced Tokens are SD-JWT VC and ISO mdoc. + + base64url: Denotes the URL-safe base64 encoding without padding as + defined in Section 2 of [RFC7515] as "Base64url Encoding". + +4. Status List + + A Status List is a byte array that contains the statuses of many + Referenced Tokens represented by one or multiple bits. A common + representation of a Status List is composed by the following + algorithm: + + 1. Each status of a Referenced Token MUST be represented with a bit- + size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for + a Referenced Token are possible, depending on the bit-size. This + limitation is intended to limit bit manipulation necessary to a + single byte for every operation and thus keeping implementations + simpler and less error prone. + + 2. The overall Status List is encoded as a byte array. Depending on + the bit-size, each byte corresponds to 8/(#bit-size) statuses + (8,4,2, or 1). The status of each Referenced Token is identified + using the index that maps to one or more specific bits within the + byte array. The index starts counting at 0 and ends with "size" + - 1 (being the last valid entry). The bits within an array are + counted from least significant bit "0" to the most significant + bit ("7"). All bits of the byte array at a particular index are + set to a status value. + + 3. The byte array is compressed using DEFLATE [RFC1951] with the + ZLIB [RFC1950] data format. Implementations are RECOMMENDED to + use the highest compression level available. + + The following example illustrates a Status List that represents the + statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the + uncompressed byte array: + + status[0] = 1 + status[1] = 0 + status[2] = 0 + status[3] = 1 + status[4] = 1 + status[5] = 1 + status[6] = 0 + status[7] = 1 + status[8] = 1 + status[9] = 1 + status[10] = 0 + status[11] = 0 + status[12] = 0 + status[13] = 1 + status[14] = 0 + status[15] = 1 + + These bits are concatenated: + + byte 0 1 2 + bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+... + values |1|0|1|1|1|0|0|1| |1|0|1|0|0|0|1|1| |0|... + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+... + index 7 6 5 4 3 2 1 0 15 ... 10 9 8 23 + \_______________/ \_______________/ + 0xB9 0xA3 + +4.1. Status List in JSON Format + + This section defines the data structure for a JSON-encoded Status + List: + + * status_list: REQUIRED. JSON Object that contains a Status List. + It MUST contain at least the following claims: + + - bits: REQUIRED. JSON Integer specifying the number of bits per + Referenced Token in the Status List (lst). The allowed values + for bits are 1,2,4 and 8. + + - lst: REQUIRED. JSON String that contains the status values for + all the Referenced Tokens it conveys statuses for. The value + MUST be the base64url-encoded Status List as specified in + Section 4. + + - aggregation_uri: OPTIONAL. JSON String that contains a URI to + retrieve the Status List Aggregation for this type of + Referenced Token. See section Section 9 for further detail. + + The following example illustrates the JSON representation of the + Status List: + + byte_array = [0xb9, 0xa3] + encoded: + { + "bits": 1, + "lst": "eNrbuRgAAhcBXQ" + } + +4.2. Status List in CBOR Format + + This section defines the data structure for a CBOR-encoded Status + List: + + * The StatusList structure is a map (Major Type 5) and defines the + following entries: + + - bits: REQUIRED. Unsigned integer (Major Type 0) that contains + the number of bits per Referenced Token in the Status List. + The allowed values for bits are 1, 2, 4 and 8. + + - lst: REQUIRED. Byte string (Major Type 2) that contains the + Status List as specified in Section 4. + + - aggregation_uri: OPTIONAL. Text string (Major Type 3) that + contains a URI to retrieve the Status List Aggregation for this + type of Referenced Token. See section Section 9 for further + detail. + + The following example illustrates the CBOR representation of the + Status List in Hex: + + byte_array = [0xb9, 0xa3] + encoded: + a2646269747301636c73744a78dadbb918000217015d + + The following is the CBOR Annotated Hex output of the example above: + + a2 # map(2) + 64 # string(4) + 62697473 # "bits" + 01 # uint(1) + 63 # string(3) + 6c7374 # "lst" + 4a # bytes(10) + 78dadbb918000217015d # "xÚÛ¹\x18\x00\x02\x17\x01]" + +5. Status List Token + + A Status List Token embeds the Status List into a token that is + cryptographically signed and protects the integrity of the Status + List. This allows for the Status List Token to be hosted by third + parties or be transferred for offline use cases. + + This section specifies Status List Tokens in JSON Web Token (JWT) and + CBOR Web Token (CWT) format. + +5.1. Status List Token in JWT Format + + The Status List Token MUST be encoded as a "JSON Web Token (JWT)" + according to [RFC7519]. + + The following content applies to the JWT Header: + + * typ: REQUIRED. The JWT type MUST be statuslist+jwt. + + The following content applies to the JWT Claims Set: + + * sub: REQUIRED. As generally defined in [RFC7519]. The sub + (subject) claim MUST specify the URI of the Status List Token. + The value MUST be equal to that of the uri claim contained in the + status_list claim of the Referenced Token. + + * iat: REQUIRED. As generally defined in [RFC7519]. The iat + (issued at) claim MUST specify the time at which the Status List + Token was issued. + + * exp: OPTIONAL. As generally defined in [RFC7519]. The exp + (expiration time) claim, if present, MUST specify the time at + which the Status List Token is considered expired by the Status + Issuer. + + * ttl: OPTIONAL. The ttl (time to live) claim, if present, MUST + specify the maximum amount of time, in seconds, that the Status + List Token can be cached by a consumer before a fresh copy SHOULD + be retrieved. The value of the claim MUST be a positive number + encoded in JSON as a number. + + * status_list: REQUIRED. The status_list (status list) claim MUST + specify the Status List conforming to the rules outlined in + Section 4.1. + + The following additional rules apply: + + 1. The JWT MAY contain other claims. + + 2. The JWT MUST be secured using a cryptographic signature or MAC + algorithm. Relying Parties MUST reject JWTs with an invalid + signature. + + 3. Relying Parties MUST reject JWTs that are not valid in all other + respects per "JSON Web Token (JWT)" [RFC7519]. + + 4. Application of additional restrictions and policy are at the + discretion of the Relying Party. + + The following is a non-normative example for a Status List Token in + JWT format: + + { + "alg": "ES256", + "kid": "12", + "typ": "statuslist+jwt" + } + . + { + "exp": 2291720170, + "iat": 1686920170, + "status_list": { + "bits": 1, + "lst": "eNrbuRgAAhcBXQ" + }, + "sub": "https://example.com/statuslists/1", + "ttl": 43200 + } + +5.2. Status List Token in CWT Format + + The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" + according to [RFC8392]. + + The following content applies to the CWT protected header: + + * 16 (type): REQUIRED. The type of the CWT MUST be statuslist+cwt + as defined in [RFC9596]. + + The following content applies to the CWT Claims Set: + + * 2 (subject): REQUIRED. As generally defined in [RFC8392]. The + subject claim MUST specify the URI of the Status List Token. The + value MUST be equal to that of the uri claim contained in the + status_list claim of the Referenced Token. + + * 6 (issued at): REQUIRED. As generally defined in [RFC8392]. The + issued at claim MUST specify the time at which the Status List + Token was issued. + + * 4 (expiration time): OPTIONAL. As generally defined in [RFC8392]. + The expiration time claim, if present, MUST specify the time at + which the Status List Token is considered expired by its issuer. + + * 65534 (time to live): OPTIONAL. Unsigned integer (Major Type 0). + The time to live claim, if present, MUST specify the maximum + amount of time, in seconds, that the Status List Token can be + cached by a consumer before a fresh copy SHOULD be retrieved. The + value of the claim MUST be a positive number. + + * 65533 (status list): REQUIRED. The status list claim MUST specify + the Status List conforming to the rules outlined in Section 4.2. + + The following additional rules apply: + + 1. The CWT MAY contain other claims. + + 2. The CWT MUST be secured using a cryptographic signature or MAC + algorithm. Relying Parties MUST reject CWTs with an invalid + signature. + + 3. Relying Parties MUST reject CWTs that are not valid in all other + respects per "CBOR Web Token (CWT)" [RFC8392]. + + 4. Application of additional restrictions and policy are at the + discretion of the Relying Party. + + The following is a non-normative example for a Status List Token in + CWT format in Hex: + + d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168 + 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a + 648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb + b918000217015d58404898b20c53c0f91e3db499bf8d0ee12ee6044b9456613a801d + 91c745abf4e7d551af39bcc78949591b5d4bc20066c2b38ede12ccbd8503b55de756 + ab6119dc41 + + The following is the CBOR Annotated Hex output of the example above: + +d2 # tag(18) + 84 # array(4) + 53 # bytes(19) + a20126106e7374617475736c # "¢\x01&\x10nstatusl" + 6973742b637774 # "ist+cwt" + a1 # map(1) + 04 # uint(4) + 42 # bytes(2) + 3132 # "12" + 58 50 # bytes(80) + a502782168747470733a2f2f # "¥\x02x!https://" + 6578616d706c652e636f6d2f # "example.com/" + 7374617475736c697374732f # "statuslists/" + 31061a648c5bea041a8898df # "1\x06\x1ad\x8c[ê\x04\x1a\x88\x98ß" + ea19fffe19a8c019fffda264 # "ê\x19ÿþ\x19¨À\x19ÿý¢d" + 6269747301636c73744a78da # "bits\x01clstJxÚ" + dbb918000217015d # "Û¹\x18\x00\x02\x17\x01]" + 58 40 # bytes(64) + 4898b20c53c0f91e3db499bf # "H\x98²\x0cSÀù\x1e=´\x99¿" + 8d0ee12ee6044b9456613a80 # "\x8d\x0eá.æ\x04K\x94Va:\x80" + 1d91c745abf4e7d551af39bc # "\x1d\x91ÇE«ôçÕQ¯9¼" + c78949591b5d4bc20066c2b3 # "Ç\x89IY\x1b]KÂ\x00f³" + 8ede12ccbd8503b55de756ab # "\x8eÞ\x12̽\x85\x03µ]çV«" + 6119dc41 # "a\x19ÜA" + +6. Referenced Token + +6.1. Status Claim + + By including a "status" claim in a Referenced Token, the Issuer is + referencing a mechanism to retrieve status information about this + Referenced Token. The claim contains members used to reference to a + Status List Token as defined in this specification. Other members of + the "status" object may be defined by other specifications. This is + analogous to "cnf" claim in Section 3.1 of [RFC7800] in which + different authenticity confirmation methods can be included. + +6.2. Referenced Token in JOSE + + The Referenced Token MAY be encoded as a "JSON Web Token (JWT)" + according to [RFC7519] or other formats based on JOSE. + + The following content applies to the JWT Claims Set: + + * status: REQUIRED. The status (status) claim MUST specify a JSON + Object that contains at least one reference to a status mechanism. + + - status_list: REQUIRED when the status mechanism defined in this + specification is used. It contains a reference to a Status + List Token. It MUST at least contain the following claims: + + o idx: REQUIRED. The idx (index) claim MUST specify an + Integer that represents the index to check for status + information in the Status List for the current Referenced + Token. The value of idx MUST be a non-negative number, + containing a value of zero or greater. + + o uri: REQUIRED. The uri (URI) claim MUST specify a String + value that identifies the Status List Token containing the + status information for the Referenced Token. The value of + uri MUST be a URI conforming to [RFC3986]. + + Application of additional restrictions and policy are at the + discretion of the Relying Party. + + The following is a non-normative example for a decoded header and + payload of a Referenced Token: + + { + "alg": "ES256", + "kid": "11" + } + . + { + "status": { + "status_list": { + "idx": 0, + "uri": "https://example.com/statuslists/1" + } + } + } + + SD-JWT-based Verifiable Credentials [SD-JWT.VC] introduce the usage + of status mechanism in Section 3.2.2.2. The "status" object uses the + same encoding as a JWT as defined in Section 6.2. + + The following is a non-normative example for a Referenced Token in + SD-JWT-VC serialized form as received from an Issuer: + + eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb + Ikh2cktYNmZQVjB2OUtfeUNWRkJpTEZIc01heGNEXzExNEVtNlZUOHgxbGciXSwgImlz + cyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwMDAw + LCAiZXhwIjogMTg4MzAwMDAwMCwgInN1YiI6ICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFl + Ny0yMTkxMjJhOWVjMmMiLCAic3RhdHVzIjogeyJzdGF0dXNfbGlzdCI6IHsiaWR4Ijog + MCwgInVyaSI6ICJodHRwczovL2V4YW1wbGUuY29tL3N0YXR1c2xpc3RzLzEifX0sICJf + c2RfYWxnIjogInNoYS0yNTYifQ.-kgS-R-Z4DEDlqb8kb6381_gHHNatsoF1fcVKZk3M + 06CrnV8F8k9d2w2V_YAOvgcb0f11FqDFezXBXH30d4vcw~WyIyR0xDNDJzS1F2ZUNmR2 + ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd~WyJlbHVWN + U9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0~WyI2S + Wo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd~ + WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ~WyJRZ19PN + jR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTN + EdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnU + nJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotR + GYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4V + GpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0~ + + Resulting payload of the example above: + + { + "_sd": [ + "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg" + ], + "iss": "https://example.com/issuer", + "iat": 1683000000, + "exp": 1883000000, + "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", + "status": { + "status_list": { + "idx": 0, + "uri": "https://example.com/statuslists/1" + } + }, + "_sd_alg": "sha-256" + } + +6.3. Referenced Token in COSE + + The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" + object according to [RFC8392] or other formats based on COSE. + + The following content applies to the CWT Claims Set: + + * 65535 (status): REQUIRED. The status claim is encoded as a Status + CBOR structure and MUST include at least one data item that refers + to a status mechanism. Each data item in the Status CBOR + structure comprises a key-value pair, where the key must be a CBOR + text string (Major Type 3) specifying the identifier of the status + mechanism, and the corresponding value defines its contents. This + specification defines the following data items: + + - status_list (status list): REQUIRED when the status mechanism + defined in this specification is used. It has the same + definition as the status_list claim in Section 6.2 but MUST be + encoded as a StatusListInfo CBOR structure with the following + fields: + + o idx: REQUIRED. Unsigned integer (Major Type 0) The idx + (index) claim MUST specify an Integer that represents the + index to check for status information in the Status List for + the current Referenced Token. The value of idx MUST be a + non-negative number, containing a value of zero or greater. + + o uri: REQUIRED. Text string (Major Type 3). The uri (URI) + claim MUST specify a String value that identifies the Status + List Token containing the status information for the + Referenced Token. The value of uri MUST be a URI conforming + to [RFC3986]. + + Application of additional restrictions and policy are at the + discretion of the Relying Party. + + The following is a non-normative example of a Referenced Token in CWT + format in Hex: + + d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861 + 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69 + 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f + 7374617475736c697374732f315840f0c1b76da95815a3416827480a8d52e1437f51 + 96ddaf36c527ff6e2db99d0fa7f9aa57804a150733513032a85ba8f2de81c570bd43 + bd67f8512ec6a52c23e410 + + The following is the CBOR Annotated Hex output of the example above: + + d2 # tag(18) + 84 # array(4) + 43 # bytes(3) + a10126 # "¡\x01&" + a1 # map(1) + 04 # uint(4) + 42 # bytes(2) + 3132 # "12" + 58 66 # bytes(102) + a50265313233343501736874 # "¥\x02e12345\x01sht" + 7470733a2f2f6578616d706c # "tps://exampl" + 652e636f6d061a648c5bea04 # "e.com\x06\x1ad\x8c[ê\x04" + 1a8898dfea19ffffa16b7374 # "\x1a\x88\x98ßê\x19ÿÿ¡kst" + 617475735f6c697374a26369 # "atus_list¢ci" + 647800637572697821687474 # "dx\x00curix!htt" + 70733a2f2f6578616d706c65 # "ps://example" + 2e636f6d2f7374617475736c # ".com/statusl" + 697374732f31 # "ists/1" + 58 40 # bytes(64) + f0c1b76da95815a341682748 # "ðÁ·m©X\x15£Ah'H" + 0a8d52e1437f5196ddaf36c5 # "\x0a\x8dRáC\x7fQ\x96ݯ6Å" + 27ff6e2db99d0fa7f9aa5780 # "'ÿn-¹\x9d\x0f§ùªW\x80" + 4a150733513032a85ba8f2de # "J\x15\x073Q02¨[¨òÞ" + 81c570bd43bd67f8512ec6a5 # "\x81Åp½C½gøQ.Æ¥" + 2c23e410 # ",#ä\x10" + + ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by + introducing the status parameter in the Mobile Security Object (MSO) + as specified in Section 9.1.2. The status parameter uses the same + encoding as a CWT as defined in Section 6.3. + + It is RECOMMENDED to use status for the label of the field that + contains the Status CBOR structure. + + Application of additional restrictions and policy are at the + discretion of the Relying Party. + + The following is a non-normative example for an IssuerAuth as + specified in ISO mDL (also referred to as signed MSO) in Hex: + + 8443a10126a118215901f3308201ef30820195a00302010202140bfec7da97e048e + 15ac3dacb9eafe82e64fd07f5300a06082a8648ce3d040302302331143012060355 + 04030c0b75746f7069612069616361310b3009060355040613025553301e170d323 + 4313030313030303030305a170d3235313030313030303030305a30213112301006 + 035504030c0975746f706961206473310b300906035504061302555330593013060 + 72a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d9648c5a72a9 + a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d3a539f4d5883 + 65e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a5301c0603551d1f0415 + 30133011a00fa00d820b6578616d706c652e636f6d301e0603551d1204173015811 + 36578616d706c65406578616d706c652e636f6d301d0603551d0e0416041414e290 + 17a6c35621ffc7a686b7b72db06cd12351301f0603551d2304183016801454fa238 + 3a04c28e0d930792261c80c4881d2c00b300e0603551d0f0101ff04040302078030 + 150603551d250101ff040b3009060728818c5d050102300a06082a8648ce3d04030 + 20348003045022100b7103fd4b90529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f + 9fa1f5c2e5aa0a0220070b2822ec7ce6c56804923a85b2cfbffd054cf9a915f070c + fef7179a4bc6569590320d81859031ba766737461747573a16b7374617475735f6c + 697374a26369647819019c63757269782168747470733a2f2f6578616d706c652e6 + 36f6d2f7374617475736c697374732f3167646f6354797065756f72672e69736f2e + 31383031332e352e312e6d444c6776657273696f6e63312e306c76616c696469747 + 9496e666fa3667369676e6564c074323032342d31302d30315431333a33303a3032 + 5a6976616c696446726f6dc074323032342d31302d30315431333a33303a30325a6 + a76616c6964556e74696cc074323032352d31302d30315431333a33303a30325a6c + 76616c756544696765737473a1716f72672e69736f2e31383031332e352e31ac005 + 820a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c923da7a6f243 + 01582048701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3efe98069 + 0a4025820d11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b110985329 + 2a8f62035820a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc99 + 41095fb7a045820ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c62 + 6e94457b7d8b055820bacddb4142b3842bd555206eb5acb27ded063294995c7e7fe + fbf93ece522604d065820bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab6 + 9eb9311650a48d325307582027dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c + 5b7544fb809e02ccb3e6a0858200dbd7ccc9c7727d3d17295f1b6f1914071670ee2 + 3d4d33530c31f1f406b8e3b7095820a5beb5efadf37f21637209abc519830681cc5 + 1f334818a823fec13b29552f5ba0a5820d8047c95f9272d7d07b2c13a9f5ac2ee02 + 380ab272a165e569391d89a2152c3c0b582004939930ffb4911ef03487a153605a3 + 0368b69f2437d6d21b4c90f92bc144c3e6d6465766963654b6579496e666fa16964 + 65766963654b6579a40102200121582096313d6c63e24e3372742bfdb1a33ba2c89 + 7dcd68ab8c753e4fbd48dca6b7f9a2258201fb3269edd418857de1b39a4e4a44b92 + fa484caa722c228288f01d0c03a2c3d66f646967657374416c676f726974686d675 + 348412d3235365840b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a + 85ed800ba7acb59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50 + fe8a1c4cafe + + The following is the CBOR Diagnostic Notation of the example above: + + [ + << { + 1: -7 + } >>, + { + 33: h'308201ef30820195a00302010202140bfec7da97e048e15ac3dacb9ea + fe82e64fd07f5300a06082a8648ce3d04030230233114301206035504030c0b + 75746f7069612069616361310b3009060355040613025553301e170d3234313 + 030313030303030305a170d3235313030313030303030305a30213112301006 + 035504030c0975746f706961206473310b30090603550406130255533059301 + 306072a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d964 + 8c5a72a9a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d + 3a539f4d588365e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a530 + 1c0603551d1f041530133011a00fa00d820b6578616d706c652e636f6d301e0 + 603551d120417301581136578616d706c65406578616d706c652e636f6d301d + 0603551d0e0416041414e29017a6c35621ffc7a686b7b72db06cd12351301f0 + 603551d2304183016801454fa2383a04c28e0d930792261c80c4881d2c00b30 + 0e0603551d0f0101ff04040302078030150603551d250101ff040b300906072 + 8818c5d050102300a06082a8648ce3d0403020348003045022100b7103fd4b9 + 0529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f9fa1f5c2e5aa0a0220070b2 + 822ec7ce6c56804923a85b2cfbffd054cf9a915f070cfef7179a4bc6569' + }, + << 24( << { + "status": { + "status_list": { + "idx": 412, + "uri": "https://example.com/statuslists/1" + } + }, + "docType": "org.iso.18013.5.1.mDL", + "version": "1.0", + "validityInfo": { + "signed": 2024-10-01 13:30:02+00:00, + "validFrom": 2024-10-01 13:30:02+00:00, + "validUntil": 2025-10-01 13:30:02+00:00 + }, + "valueDigests": { + "org.iso.18013.5.1": { + 0: h'a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c92 + 3da7a6f243', + 1: h'48701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3e + fe980690a4', + 2: h'd11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b11098 + 53292a8f62', + 3: h'a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc9 + 941095fb7a', + 4: h'ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c626e + 94457b7d8b', + 5: h'bacddb4142b3842bd555206eb5acb27ded063294995c7e7fefbf93 + ece522604d', + 6: h'bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab69eb93116 + 50a48d3253', + 7: h'27dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c5b7544fb809 + e02ccb3e6a', + 8: h'0dbd7ccc9c7727d3d17295f1b6f1914071670ee23d4d33530c31f1 + f406b8e3b7', + 9: h'a5beb5efadf37f21637209abc519830681cc51f334818a823fec13 + b29552f5ba', + 10: h'd8047c95f9272d7d07b2c13a9f5ac2ee02380ab272a165e569391 + d89a2152c3c', + 11: h'04939930ffb4911ef03487a153605a30368b69f2437d6d21b4c90 + f92bc144c3e' + } + }, + "deviceKeyInfo": { + "deviceKey": { + 1: 2, + -1: 1, + -2: h'96313d6c63e24e3372742bfdb1a33ba2c897dcd68ab8c753e4fbd + 48dca6b7f9a', + -3: h'1fb3269edd418857de1b39a4e4a44b92fa484caa722c228288f01 + d0c03a2c3d6' + } + }, + "digestAlgorithm": "SHA-256" + } >> ) >>, + h'b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a85ed800ba7acb + 59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50fe8a1c4cafe' + ] + +7. Status Types + + This document defines statuses of Referenced Tokens as Status Type + values. A status describes the state, mode, condition or stage of an + entity that is represented by the Referenced Token. + + A Status List can not represent multiple statuses per Referenced + Token. If the Status List contains more than one bit per token (as + defined by bits in the Status List), then the whole value of bits + MUST describe one value. Status Types MUST have a numeric value + between 0 and 255 for their representation in the Status List. The + issuer of the Status List MUST choose an adequate bits (bit size) to + be able to describe the required Status Types for its application. + +7.1. Status Types Values + + This document creates a registry in Section 14.5 that includes the + most common Status Type values. Additional values may defined for + particular use cases. Status Types described by this document + comprise: + + * 0x00 - "VALID" - The status of the Referenced Token is valid, + correct or legal. + + * 0x01 - "INVALID" - The status of the Referenced Token is revoked, + annulled, taken back, recalled or cancelled. + + * 0x02 - "SUSPENDED" - The status of the Referenced Token is + temporarily invalid, hanging, debarred from privilege. This state + is reversible. + + * 0x03 - "APPLICATION_SPECIFIC_3" - The status of the Referenced + Token is implicitly given by the particular use case and the + meaning of this value is known out-of-band. + + * 0x0E - "APPLICATION_SPECIFIC_14" - The status of the Referenced + Token is implicitly given by the particular use case and the + meaning of this value is known out-of-band. + + * 0x0F - "APPLICATION_SPECIFIC_15" - The status of the Referenced + Token is implicitly given by the particular use case and the + meaning of this value is known out-of-band. + + The Status Issuer MUST choose an adequate bits (bit size) to be able + to describe the required Status Types for the application. + + The processing rules for JWT or CWT precede any evaluation of a + Referenced Token's status. For example, if a token is evaluated as + being expired through the "exp" (Expiration Time) but also has a + status of 0x00 ("VALID"), the token is considered expired. + +8. Verification and Processing + +8.1. Status List Request + + To obtain the Status List Token, the Relying Party MUST send an HTTP + GET request to the URI provided in the Referenced Token. + + The HTTP endpoint SHOULD support the use of Cross-Origin Resource + Sharing (CORS) [CORS] and/or other methods as appropriate to enable + Browser-Based clients to access it. + + The Relying Party SHOULD send the following Accept-Header to indicate + the requested response type: + + * "application/statuslist+jwt" for Status List Token in JWT format + + * "application/statuslist+cwt" for Status List Token in CWT format + + If the Relying Party does not send an Accept Header, the response + type is assumed to be known implicit or out-of-band. + + The following are non-normative examples for a request and response + for a Status List Token with type application/statuslist+jwt: + + GET /statuslists/1 HTTP/1.1 + Host: example.com + Accept: application/statuslist+jwt + + HTTP/1.1 200 OK + Content-Type: application/statuslist+jwt + + eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e + yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le + GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ + WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI + nR0bCI6NDMyMDB9.pSUxmCdwv3_JuXxXkM3uZhG8wp2Fmkzrl8Kwf2UHCG8xDx5HuReH + seQkLdJIa5LUPIbgfY4x7SrZwRDMO8TC9g + +8.2. Status List Response + + In the successful response, the Status Provider MUST use the + following content-type: + + * "application/statuslist+jwt" for Status List Token in JWT format + + * "application/statuslist+cwt" for Status List Token in CWT format + + In the case of "application/statuslist+jwt", the response MUST be of + type JWT and follow the rules of Section 5.1. In the case of + "application/statuslist+cwt", the response MUST be of type CWT and + follow the rules of Section 5.2. + + The HTTP response SHOULD use gzip Content-Encoding as defined in + [RFC9110]. + +8.3. Validation Rules + + Upon receiving a Referenced Token, a Relying Party MUST first perform + the validation of the Referenced Token - e.g., checking for expected + attributes, valid signature, expiration time. The processing rules + for JWT or CWT precede any evaluation of a Referenced Token's status. + For example, if a token is evaluated as being expired through the + "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the + token is considered expired. As this is out of scope of this + document, this validation is not be described here, but is expected + to be done according to the format of the Referenced Token. + + If this validation was not successful, the Referenced Token MUST be + rejected. If the validation was successful, the Relying Party MUST + perform the following validation steps to evaluate the status of the + reference token: + + 1. Check for the existence of a status claim, check for the + existence of a status_list claim within the status claim and + validate that the content of status_list adheres to the rules + defined in Section 6.2 for JWTs and Section 6.3 for CWTs. This + step can be overruled if defined within the Referenced Token + Format natively + + 2. Resolve the Status List Token from the provided URI + + 3. Validate the Status List Token: + + 1. Validate the Status List Token by following the rules defined + in section 7.2 of [RFC7519] for JWTs and section 7.2 of + [RFC8392] for CWTs + + 2. Check for the existence of the required claims as defined in + Section 5.1 and Section 5.2 depending on token type + + 4. All existing claims in the Status List Token MUST be checked + according to the rules in Section 5.1 and Section 5.2 + + 1. The subject claim (sub or 2) of the Status List Token MUST be + equal to the uri claim in the status_list object of the + Referenced Token + + 2. If the Relying Party has custom policies regarding the + freshness of the Status List Token, it SHOULD check the + issued at claim (iat or 6) + + 3. If expiration time is defined (exp or 4), it MUST be checked + if the Status List Token is expired + + 4. If the Relying Party is using a system for caching the Status + List Token, it SHOULD check the ttl claim of the Status List + Token and retrieve a fresh copy if (time status was resolved + + ttl < current time) + + 5. Decompress the Status List with a decompressor that is compatible + with DEFLATE [RFC1951] and ZLIB [RFC1950] + + 6. Retrieve the status value of the index specified in the + Referenced Token as described in Section 4. Fail if the provided + index is out of bound of the Status List + + 7. Check the status value as described in Section 7 + + If any of these checks fails, no statement about the status of the + Referenced Token can be made and the Referenced Token SHOULD be + rejected. + +8.4. Historical resolution + + By default, the status mechanism defined in this specification only + conveys information about the state of Reference Tokens at the time + the Status List Token was issued. The validity period for this + information, as defined by the issuer, is explicitly stated by the + iat (issued at) and exp (expiration time) claims for JWT, and their + corresponding ones for the CWT representation. If support for + historical status information is required, this can be achieved by + extending the request for the Status List Token as defined in + Section 8.1 with a timestamp. This feature has additional privacy + implications as described in Section 12.7. + + To obtain the Status List Token, the Relying Party MUST send an HTTP + GET request to the URI provided in the Referenced Token with the + additional query parameter time and its value being a unix timestamp. + The response for a valid request SHOULD contain a Status List Token + that was valid for that specified time or an error. + + If the Server does not support the additional query parameter, it + SHOULD return a status code of 501 (Not Implemented), or if the + requested time is not supported it SHOULD return a status code of 406 + (Not Acceptable). A Status List Token might be served via static + file hosting (e.g., leveraging a Content Delivery Network), which + would result in the client not being able to retrieve those status + codes. Thus, the client MUST verify support for this feature by + verifying that the requested timestamp is within the valid time of + the returned token signaled via iat (6 for CWT) and exp (4 for CWT). + + The following is a non-normative example for a GET request using the + time query parameter: + + GET /statuslists/1?time=1686925000 HTTP/1.1 + Host: example.com + Accept: application/statuslist+jwt + + The following is a non-normative example for a response for the above + Request: + + HTTP/1.1 200 OK + Content-Type: application/statuslist+jwt + + eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e + yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le + GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ + WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI + nR0bCI6NDMyMDB9.pSUxmCdwv3_JuXxXkM3uZhG8wp2Fmkzrl8Kwf2UHCG8xDx5HuReH + seQkLdJIa5LUPIbgfY4x7SrZwRDMO8TC9g + +9. Status List Aggregation + + Status List Aggregation is an optional mechanism to retrieve a list + of URIs to all Status List Tokens, allowing a Relying Party to fetch + all relevant Status Lists for a specific type of Referenced Token or + Issuer. This mechanism is intended to support fetching and caching + mechanisms and allow offline validation of the status of a reference + token for a period of time. + + If a Relying Party encounters an invalid Status List referenced in + the response from the Status List Aggregation endpoint, it SHOULD + continue processing the other valid Status Lists referenced in the + response. + + There are two options for a Relying Party to retrieve the Status List + Aggregation. An Issuer MAY support any of these mechanisms: + + * Issuer metadata: The Issuer of the Referenced Token publishes an + URI which links to Status List Aggregation, e.g. in publicly + available metadata of an issuance protocol + + * Status List Parameter: The Status Issuer includes an additional + claim in the Status List Token that contains the Status List + Aggregation URI. + +9.1. 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 via a VICAL extension for + ISO mDoc / mDL. + + The concrete specification on how this is implemented depends on the + specific ecosystem and is out of scope of this specification. + +9.2. Status List Parameter + + The URI to the Status List Aggregation MAY be provided as the + optional parameter aggregation_uri in the Status List itself as + explained inSection 4.2 and Section 4.1 respectively. A Relying + Party may use this URI to retrieve an up-to-date list of relevant + Status Lists. + +9.3. Status List Aggregation in JSON Format + + This section defines the structure for a JSON-encoded Status List + Aggregation: + + * status_lists: REQUIRED. JSON array of strings that contains URIs + linking to Status List Tokens. + + The Status List Aggregation URI provides a list of Status List URIs. + This aggregation in JSON and the media type return SHOULD be + application/json. A Relying Party can iterate through this list and + fetch all Status List Tokens before encountering the specific URI in + a Referenced Token. + + The following is a non-normative example for media type application/ + json: + + { + "status_lists" : [ + "https://example.com/statuslists/1", + "https://example.com/statuslists/2", + "https://example.com/statuslists/3" + ] + } + +10. Further Examples + +10.1. Status List with 2-Bit Status Values in JSON format + + In this example, the Status List additionally includes the Status + Type "SUSPENDED". As the Status Type value for "SUSPENDED" is 0x02 + and does not fit into 1 bit, the "bits" is required to be 2. + + This example Status List represents the status of 12 Referenced + Tokens, requiring 24 bits (3 bytes) of status. + + status[0] = 1 + status[1] = 2 + status[2] = 0 + status[3] = 3 + status[4] = 0 + status[5] = 1 + status[6] = 0 + status[7] = 1 + status[8] = 1 + status[9] = 2 + status[10] = 3 + status[11] = 3 + + These bits are concatenated: + + byte 0 1 2 + bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / + status 3 0 2 1 1 0 1 0 3 3 2 1 + index 3 2 1 0 7 6 5 4 11 10 9 8 + \___________/ \___________/ \___________/ + 0xC9 0x44 0xF9 + + Resulting in the byte array and compressed/base64url-encoded Status + List: + + byte_array = [0xc9, 0x44, 0xf9] + encoded: + { + "bits": 2, + "lst": "eNo76fITAAPfAgc" + } + +11. Security Considerations + +11.1. Correct decoding and parsing of the encoded Status List + + Implementers should be particularly careful for the correct parsing + and decoding of the Status List. Incorrect implementations might + check the index on the wrong data or miscalculate the bit and byte + index leading to an erroneous status of the Referenced Token. + Beware, that bits are indexed (bit order) from least significant bit + to most significant bit (also called "right to left") while bytes are + indexed (byte order) in their natural incrementing byte order + (usually written for display purpose from left to write). Endianness + does not apply here because each status value fits within a single + byte. + + Implementations are RECOMMENDED to verify correctness using the test + vectors given by this specification. + +11.2. Security Guidance for JWT and CWT + + A Status List Token in the JWT format should follow the security + considerations of [RFC7519] and the best current practices of + [RFC8725]. + + A Status List Token in the CWT format should follow the security + considerations of [RFC8392]. + +11.3. Cached and Stale Status Lists + + When Relying Parties fetch the Status List, they need to be aware of + its up-to-date status. The 'ttl' (time-to-live) claim in the Status + List Token provides one mechanism for setting a maximum cache time + for the fetched data. This property permits distribution of a Status + List to a CDN or other distribution mechanism while giving guidance + to consumers of the Status List on how often they need to fetch a + fresh copy of the Status List even if that Status List is not + expired. + +12. Privacy Considerations + +12.1. Observability of Issuers + + The main privacy consideration for a Status List, especially in the + context of the Issuer-Holder-Verifier model [SD-JWT.VC], is to + prevent the Issuer from tracking the usage of the Referenced Token + when the status is being checked. If an Issuer offers status + information by referencing a specific token, this would enable him to + create a profile for the issued token by correlating the date and + identity of Relying Parties, that are requesting the status. + + The Status List approaches these privacy implications by integrating + the status information of many Referenced Tokens into the same list. + Therefore, the Issuer does not learn for which Referenced Token the + Relying Party is requesting the Status List. The privacy of the + Holder is protected by the anonymity within the set of Referenced + Tokens in the Status List, also called herd privacy. This limits the + possibilities of tracking by the Issuer. + + The herd privacy is depending on the number of entities within the + Status List called its size. A larger size results in better privacy + but also impacts the performance as more data has to be transferred + to read the Status List. + + Additionally, the Issuer may analyse data from the HTTP request to + identify the Relying Party, e.g. through the sender's IP address. + + This behaviour may be mitigated by: + + * private relay protocols or other mechanism hiding the original + sender like [RFC9458]. + + * using trusted Third Party Hosting, see Section 12.6. + +12.2. Malicious Issuers + + A malicious Issuer could bypass the privacy benefits of the herd + privacy by generating a unique Status List for every Referenced + Token. By these means, he could maintain a mapping between + Referenced Tokens and Status Lists and thus track the usage of + Referenced Tokens by utilizing this mapping for the incoming + requests. This malicious behaviour could be detected by Relying + Parties that request large amounts of Referenced Tokens by comparing + the number of different Status Lists and their sizes. + +12.3. Observability of Relying Parties + + Once the Relying Party receives the Referenced Token, this enables + him to request the Status List to validate its status through the + provided uri parameter and look up the corresponding index. However, + the Relying Party may persistently store the uri and index of the + Referenced Token to request the Status List again at a later time. + By doing so regularly, the Relying Party may create a profile of the + Referenced Token's validity status. This behaviour may be intended + as a feature, e.g. for a KYC process that requires regular validity + checks, but might also be abused in cases where this is not intended + and unknown to the Holder, e.g. profiling the suspension of a driving + license or checking the employment status of an employee credential. + + This behaviour could be mitigated by: + + * regular re-issuance of the Referenced Token, see Section 13.1. + +12.4. Observability of Outsiders + + 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 Section 8.4 + + * disable the Status List Aggregation Section 9 + + * 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 + +12.5. Unlinkability + + Colluding Issuers and Relying Parties have the possibility to link + two transactions, as the tuple of uri and index inside the Referenced + Token are unique and therefore traceable data. By comparing the + status claims of received Referenced Tokens, two colluding Relying + Parties could determine that they have interacted with the same user + or an Issuer could trace the usage of its issued Referenced Token by + colluding with various Relying Parties. It is therefore recommended + to use Status Lists for Referenced Token formats that have similar + unlinkability properties. + + To avoid privacy risks for colluding Relying Parties, it is + RECOMMENDED that Issuers use batch issuance to issue multiple tokens, + see Section 13.1. + + To avoid further correlatable information by the values of uri and + index, Issuers are RECOMMENDED to: + + * 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 + +12.6. Third Party Hosting + + If the roles of the Issuer and the Status Provider are performed by + two different entities, this may give additional privacy assurances + as the Issuer has no means to identify the Relying Party or its + request. + + Third Party hosting may also allow for greater scalability, as the + Status List Tokens may be served by operators with greater resources, + like CDNs. + +12.7. Historical Resolution + + By default, this specification only supports providing Status List + information for the most recent status information and does not allow + the lookup of historical information like a validity state at a + specific point in time. There exists optional support for a query + parameter that allows these kind of historic lookups as described in + Section 8.4. There are scenarios where such a functionality is + necessary, but this feature should only be implemented when the + scenario and the consequences of enabling historical resolution are + fully understood. + + There are strong privacy concerns that have to be carefully taken + into considerations when providing a mechanism that allows historic + requests for status information - see Section 12.3 for more details. + Support for this functionality is optional and Implementers are + RECOMMENDED to not support historic requests unless there are strong + reasons to do so and after carefully considering the privacy + implications. + +13. Implementation Considerations + +13.1. Token Lifecycle + + The lifetime of a Status List Token depends on the lifetime of its + Referenced Tokens. Once all Referenced Tokens are expired, the + Issuer may stop serving the Status List Token. + + Referenced Tokens may be regularly re-issued to mitigate linkability + of presentations to Relying Parties. In this case, every re-issued + Referenced Token MUST have a fresh Status List entry in order to + prevent this becoming possible source of correlation. + + Referenced Tokens may also be issued in batches, such that Holders + can use individual tokens for every transaction. In this case, every + Referenced Token MUST have a dedicated Status List entry. Revoking + batch issued Referenced Tokens might reveal this correlation later + on. + +13.2. Default Values and Double Allocation + + Implementations producing Status Lists are RECOMMENDED to initialize + the Status List byte array with a default value and provide this as + an initialization parameter to the Issuer. The Issuer is RECOMMENDED + to use a default value that represents the most common value for its + Referenced Tokens to avoid an update during issuance. + + Implementations producing Status Lists are RECOMMENDED to prevent + double allocation, i.e. re-using the same uri and index for multiple + Referenced Tokens. The Issuer MUST prevent any unintended double + allocation by using the Status List. + +13.3. Status List Size + + The Status List Issuer may increase the size of a Status List if it + requires indices for additional Referenced Tokens. It is RECOMMENDED + that the size of a Status List in bits is divisible in bytes (8 bits) + without a remainder, i.e. size-in-bits % 8 = 0. + + The Status List Issuer may chunk its Referenced Tokens into multiple + Status Lists to reduce the transmission size of an individual Status + List Token. This may be useful for setups where some entities + operate in constrained environments, e.g. for mobile internet or + embedded devices. + +13.4. Status List Formats + + This specification defines 2 different token formats of the Status + List: + + * JWT + + * CWT + + This specification states no requirements to not mix different + formats like a CBOR based Referenced Token using a JWT for the Status + List, but the expectation is that within an ecosystem, a choice for + specific formats is made. Within such an ecosystem, only support for + those selected variants is required and implementations should know + what to expect via a profile. + +14. IANA Considerations + +14.1. JSON Web Token Claims Registration + + This specification requests registration of the following Claims in + the IANA "JSON Web Token Claims" registry [IANA.JWT] established by + [RFC7519]. + +14.1.1. Registry Contents + + * Claim Name: status + + * Claim Description: Reference to a status or validity mechanism + containing up-to-date status information on the JWT. + + * Change Controller: IETF + + * Specification Document(s): Section 6.1 of this specification + + + + * Claim Name: status_list + + * Claim Description: A status list containing up-to-date status + information on multiple tokens. + + * Change Controller: IETF + + * Specification Document(s): Section 5.1 of this specification + + + + * Claim Name: ttl + + * Claim Description: Time to Live + + * Change Controller: IETF + + * Specification Document(s): Section 5.1 of this specification + +14.2. JWT Status Mechanism Methods Registry + + This specification establishes the IANA "Status Mechanism Methods" + registry for JWT "status" member values. The registry records the + status mechanism method member and a reference to the specification + that defines it. + +14.2.1. Registration Template + + Status Method Value: + + The name requested (e.g., "status_list"). The name is case + sensitive. Names may not match other registered names in a case- + insensitive manner unless the Designated Experts state that there + is a compelling reason to allow an exception. + + Status Method Description: + + Brief description of the status mechanism method. + + Change Controller: + + For IETF Stream RFCs, list the IETF. For others, give the name of + the responsible party. Other details (e.g., postal address, email + address, home page URI) may also be included. + + Specification Document(s): + + Reference to the document or documents that specify the parameter, + preferably including URIs that can be used to retrieve copies of + the documents. An indication of the relevant sections may also be + included but is not required. + +14.2.2. Initial Registry Contents + + * Status Method Value: status_list + + * Status Method Description: A status list containing up-to-date + status information on multiple tokens. + + * Change Controller: IETF + + * Specification Document(s): Section 6.2 of this specification + +14.3. CBOR Web Token Claims Registration + + This specification requests registration of the following Claims in + the IANA "CBOR Web Token (CWT) Claims" registry [IANA.CWT] + established by [RFC8392]. + +14.3.1. Registry Contents + + + + * Claim Name: status + + * Claim Description: Reference to a status or validity mechanism + containing up-to-date status information on the CWT. + + * JWT Claim Name: status + + * Claim Key: TBD (requested assignment 65535) + + * Claim Value Type: map + + * Change Controller: IETF + + * Reference: Section 6.1 of this specification + + + + * Claim Name: status_list + + * Claim Description: A status list containing up-to-date status + information on multiple tokens. + + * JWT Claim Name: status_list + + * Claim Key: TBD (requested assignment 65533) + + * Claim Value Type: map + + * Change Controller: IETF + + * Specification Document(s): Section 5.2 of this specification + + + + * Claim Name: ttl + + * Claim Description: Time to Live + + * JWT Claim Name: ttl + + * Claim Key: TBD (requested assignment 65534) + + * Claim Value Type: unsigned integer + + * Change Controller: IETF + + * Specification Document(s): Section 5.2 of this specification + +14.4. CWT Status Mechanism Methods Registry + + This specification establishes the IANA "Status Mechanism Methods" + registry for CWT "status" member values. The registry records the + status mechanism method member and a reference to the specification + that defines it. + +14.4.1. Registration Template + + Status Method Value: + + The name requested (e.g., "status_list"). The name is case + sensitive. Names may not match other registered names in a case- + insensitive manner unless the Designated Experts state that there + is a compelling reason to allow an exception. + + Status Method Description: + + Brief description of the status mechanism method. + + Change Controller: + + For IETF Stream RFCs, list the IETF. For others, give the name of + the responsible party. Other details (e.g., postal address, email + address, home page URI) may also be included. + + Specification Document(s): + + Reference to the document or documents that specify the parameter, + preferably including URIs that can be used to retrieve copies of + the documents. An indication of the relevant sections may also be + included but is not required. + +14.4.2. Initial Registry Contents + + * Status Method Value: status_list + + * Status Method Description: A status list containing up-to-date + status information on multiple tokens. + + * Change Controller: IETF + + * Specification Document(s): Section 6.3 of this specification + +14.5. Status Types Registry + + This specification establishes the IANA "Status Types" registry for + Status List values. The registry records the a human readable label, + the bit representation and a common description for it. + +14.5.1. Registration Template + + Status Type Name: + + The name is a human-readable case insensitive label for the Status + Type that helps to talk about a Status of Referenced Token in + common language. + + Status Type Description: + + Brief description of the Status Type and optional examples. + + Status Type value: + + The bit representation of the Status Type in a byte hex + representation. Values are filled up with zeros if they have less + than 8 bits. + + Change Controller: + + For IETF Stream RFCs, list the IETF. For others, give the name of + the responsible party. Other details (e.g., postal address, email + address, home page URI) may also be included. + + Specification Document(s): + + Reference to the document or documents that specify the parameter, + preferably including URIs that can be used to retrieve copies of + the documents. An indication of the relevant sections may also be + included but is not required. + +14.5.2. Initial Registry Contents + + * Status Type Name: VALID + + * Status Type Description: The status of the Referenced Token is + valid, correct or legal. + + * Status Type value: 0x00 + + * Change Controller: IETF + + * Specification Document(s): Section 7 of this specification + + + + * Status Type Name: INVALID + + * Status Type Description: The status of the Referenced Token is + revoked, annulled, taken back, recalled or cancelled. + + * Status Type value: 0x01 + + * Change Controller: IETF + + * Specification Document(s): Section 7 of this specification + + + + * Status Type Name: SUSPENDED + + * Status Type Description: The status of the Referenced Token is + temporarily invalid, hanging, debarred from privilege. This state + is reversible. + + * Status Type value: 0x02 + + * Change Controller: IETF + + * Specification Document(s): Section 7 of this specification + + + + * Status Type Name: APPLICATION_SPECIFIC_3 + + * Status Type Description: The status of the Referenced Token is + implicitly given by the particular use case and the meaning of + this value is known out-of-band. + + * Status Type value: 0x03 + + * Change Controller: IETF + + * Specification Document(s): Section 7 of this specification + + + + * Status Type Name: APPLICATION_SPECIFIC_14 + + * Status Type Description: The status of the Referenced Token is + implicitly given by the particular use case and the meaning of + this value is known out-of-band. + + * Status Type value: 0x0E + + * Change Controller: IETF + + * Specification Document(s): Section 7 of this specification + + + + * Status Type Name: APPLICATION_SPECIFIC_15 + + * Status Type Description: The status of the Referenced Token is + implicitly given by the particular use case and the meaning of + this value is known out-of-band. + + * Status Type value: 0x0F + + * Change Controller: IETF + + * Specification Document(s): Section 6.2 of this specification + + + +14.6. Media Type Registration + + This section requests registration of the following media types + [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the + manner described in [RFC6838]. + + To indicate that the content is an JWT-based Status List: + + * Type name: application + + * Subtype name: statuslist+jwt + + * Required parameters: n/a + + * Optional parameters: n/a + + * Encoding considerations: See Section 5.1 of this specification + + * Security considerations: See Section 11 of this specification + + * Interoperability considerations: n/a + + * Published specification: this specification + + * Applications that use this media type: Applications using this + specification for updated status information of tokens + + * Fragment identifier considerations: n/a + + * Additional information: n/a + + * Person & email address to contact for further information: Paul + Bastian, paul.bastian@posteo.de + + * Intended usage: COMMON + + * Restrictions on usage: none + + * Author: Paul Bastian, paul.bastian@posteo.de + + * Change controller: IETF + + * Provisional registration? No + + To indicate that the content is an CWT-based Status List: + + * Type name: application + + * Subtype name: statuslist+cwt + + * Required parameters: n/a + + * Optional parameters: n/a + + * Encoding considerations: See Section 5.2 of this specification + + * Security considerations: See Section 11 of this specification + + * Interoperability considerations: n/a + + * Published specification: this specification + + * Applications that use this media type: Applications using this + specification for updated status information of tokens + + * Fragment identifier considerations: n/a + + * Additional information: n/a + + * Person & email address to contact for further information: Paul + Bastian, paul.bastian@posteo.de + + * Intended usage: COMMON + + * Restrictions on usage: none + + * Author: Paul Bastian, paul.bastian@posteo.de + + * Change controller: IETF + + * Provisional registration? No + +15. References + +15.1. Normative References + + [CORS] WHATWG, "Fetch Living Standard", n.d., + . + + [IANA.CWT] IANA, "CBOR Web Token (CWT) Claims", n.d., + . + + [IANA.JOSE] + IANA, "JSON Object Signing and Encryption (JOSE)", n.d., + . + + [IANA.JWT] IANA, "JSON Web Token Claims", n.d., + . + + [IANA.MediaTypes] + IANA, "Media Types", n.d., + . + + [RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format + Specification version 3.3", RFC 1950, + DOI 10.17487/RFC1950, May 1996, + . + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification + version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, + . + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + DOI 10.17487/RFC2046, November 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, . + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web + Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May + 2015, . + + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + . + + [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, + "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, + May 2018, . + + [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best + Current Practices", BCP 225, RFC 8725, + DOI 10.17487/RFC8725, February 2020, + . + + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + . + + [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): + Structures and Process", STD 96, RFC 9052, + DOI 10.17487/RFC9052, August 2022, + . + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + . + + [RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and + Encryption (COSE) "typ" (type) Header Parameter", + RFC 9596, DOI 10.17487/RFC9596, June 2024, + . + +15.2. Informative References + + [ISO.mdoc] ISO/IEC JTC 1/SC 17, "ISO/IEC 18013-5:2021 ISO-compliant + driving licence", n.d.. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + . + + [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", + RFC 7662, DOI 10.17487/RFC7662, October 2015, + . + + [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- + Possession Key Semantics for JSON Web Tokens (JWTs)", + RFC 7800, DOI 10.17487/RFC7800, April 2016, + . + + [RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, + DOI 10.17487/RFC9458, January 2024, + . + + [SD-JWT.VC] + Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based + Verifiable Credentials (SD-JWT VC)", Work in Progress, + Internet-Draft, draft-ietf-oauth-sd-jwt-vc-06, 13 November + 2024, . + +Acknowledgments + + We would like to thank Brian Campbell, Filip Skokan, Francesco + Marino, Guiseppe De Marco, Kristina Yasuda, Markus Kreusch, Martijn + Haring, Michael B. Jones, Mike Prorock, Oliver Terbu, Orie Steele, + Timo Glastra and Torsten Lodderstedt + + for their valuable contributions, discussions and feedback to this + specification. + +Document History + + -06 + + * remove unsigned options (json/cbor) of status list + + * add section about mixing status list formats and media type + + * fixes from IETF review + + -05 + + * add optional support for historical requests + + * update CBOR claim definitions + + * improve section on Status Types and introduce IANA registry for it + + * add Status Issuer and Status Provider role description to the + introduction/terminology + + * add information on third party hosting to security consideration + + * remove constraint that Status List Token must not use a MAC + + -04 + + * add mDL example as Referenced Token and consolidate CWT and CBOR + sections + + * add implementation consideration for Default Values, Double + Allocation and Status List Size + + * add privacy consideration on using private relay protocols + + * add privacy consideration on observability of outsiders + + * add security considerations on correct parsing and decoding + + * remove requirement for matching iss claim in Referenced Token and + Status List Token + + * add sd-jwt-vc example + + * fix CWT status_list map encoding + + * editorial fixes + + * add CORS considerations to the http endpoint + + * fix reference of Status List in CBOR format + + * added status_list CWT claim key assigned + + * move base64url definition to terminology + + -03 + + * remove unused reference to RFC9111 + + * add validation rules for status list token + + * introduce the status list aggregation mechanism + + * relax requirements for status_list claims to contain other + parameters + + * change cwt referenced token example to hex and annotated hex + + * require TLS only for fetching Status List, not for Status List + Token + + * remove the undefined phrase Status List endpoint + + * remove http caching in favor of the new ttl claim + + * clarify the sub claim of Status List Token + + * relax status_list iss requirements for CWT + + * Fixes missing parts & iana ttl registration in CWT examples + + -02 + + * add ttl claim to Status List Token to convey caching + + * relax requirements on referenced token + + * clarify Deflate / zlib compression + + * make a reference to the Issuer-Holder-Verifier model of SD-JWT VC + + * add COSE/CWT/CBOR encoding + + -01 + + * Rename title of the draft + + * add design consideration to the introduction + + * Change status claim to in referenced token to allow re-use for + other mechanisms + + * Add IANA Registry for status mechanisms + + * restructure the sections of this document + + * 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 + + * Initial draft after working group adoption + + * update acknowledgments + + * renamed Verifier to Relying Party + + * added IANA consideration + + [ draft-ietf-oauth-status-list ] + + -01 + + * Applied editorial improvements suggested by Michael Jones. + + -00 + + * Initial draft + +Authors' Addresses + + Tobias Looker + MATTR + Email: tobias.looker@mattr.global + + + Paul Bastian + Email: paul.bastian@posteo.de + + + Christian Bormann + Robert Bosch GmbH + Email: chris.bormann@gmx.de diff --git a/tl/issue-182/index.html b/tl/issue-182/index.html new file mode 100644 index 0000000..2f16d54 --- /dev/null +++ b/tl/issue-182/index.html @@ -0,0 +1,45 @@ + + + + oauth-wg/draft-ietf-oauth-status-list tl/issue-182 preview + + + + +

Editor's drafts for tl/issue-182 branch of oauth-wg/draft-ietf-oauth-status-list

+ + + + + + +
Token Status Listplain textsame as main
+ + +