Token Status List

1.1. Example Use Cases

An example of the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of [RFC6749]. Token Introspection [RFC7662] defines another way to determine the status of an issued access token, but it requires the party trying to validate the state of access tokens to directly contact the 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].¶

1.2. Rationale

Revocation mechanisms are an essential part of 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. Another alternative is short-lived Referenced Tokens with regular re-issuance, but this puts additional burden on the Issuer's infrastructure.¶

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.¶

1.3. 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 define an extension point that enables other mechanisms to convey information about the status of a Referenced Token¶

1.4. Prior Work

Representing a status with bits in array is a rather old and well-known concept in computer science and there has been prior work to use this for revocation and status management such as a paper by Smith et al. [smith2020let] that proposed a mechanism called Certificate Revocation Vectors based on xz compressed bit vectors for each expiration day and the W3C bit Status List [W3C.SL] that similarly uses a compressed bit representation.¶

1.5. Status Mechanisms Registry

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

Other status mechanisms may have different tradeoffs regarding security, privacy, scalability and complexity. The privacy and security considerations in this document only represent the properties of the Status List mechanism.¶

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 or Issuer. See section Section 9 for further details.¶

The following example illustrates the JSON representation of the Status List with bit-size 1 from the example above:¶

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

The following example illustrates the JSON representation of the Status List with bit-size 2 from the example above:¶

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

See section Appendix "Test vectors for Status List encoding" for more test vectors.¶

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]"

See section Appendix "Test vectors for Status List encoding" for more test vectors.¶

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 policies are at the discretion of the Relying Party.¶

The following is a non-normative example of 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 protected header of the CWT:¶

• 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 policies are at the discretion of the Relying Party.¶

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

d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168
747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a
648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb
b918000217015d5840b973b7e73c75316630cc7c28caad342638a91c6b68299d59c4
dcbf9b6162b526e7e5511e54cf5453fc39180896a96f9107bf6a5cdb1cacc5589909
f0fc4bf023

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)
      b973b7e73c75316630cc7c28  #       "¹s·ç<u1f0Ì|("
      caad342638a91c6b68299d59  #       "Ê\xad4&8©\x1ckh)\x9dY"
      c4dcbf9b6162b526e7e5511e  #       "ÄÜ¿\x9babµ&çåQ\x1e"
      54cf5453fc39180896a96f91  #       "TÏTSü9\x18\x08\x96©o\x91"
      07bf6a5cdb1cacc5589909f0  #       "\x07¿j\Û\x1c¬ÅX\x99\x09ð"
      fc4bf023                  #       "üKð#"

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 policies are at the discretion of the Relying Party.¶

The following is a non-normative example of 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 a 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 of 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~

The 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 policies 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
7374617475736c697374732f315840e6285be7a7829ff5f87cc4137099f2008c25f6
947294b628f83076f2eb8eef232545e4b2e5d9602978bc8cdfdf8aa9e216ded4066c
c75a6f0a617dbf4285b13d

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)
      e6285be7a7829ff5f87cc413  #       "æ([ç§\x82\x9fõø|Ä\x13"
      7099f2008c25f6947294b628  #       "p\x99ò\x00\x8c%ö\x94r\x94¶("
      f83076f2eb8eef232545e4b2  #       "ø0vòë\x8eï#%Eä²"
      e5d9602978bc8cdfdf8aa9e2  #       "åÙ`)x¼\x8cßß\x8a©â"
      16ded4066cc75a6f0a617dbf  #       "\x16ÞÔ\x06lÇZo\x0aa}¿"
      4285b13d                  #       "B\x85±="

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 policies are at the discretion of the Relying Party.¶

The following is a non-normative example of 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.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.¶

The Status Type value 0x03 and Status Type values in the range 0x0B until 0x0F are permanently reserved as application specific. Meaning the processing of Status Types using these values is application specific. All other Status Type values are reserved for future registration.¶

The processing rules for Referenced Tokens (such as 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.¶

See Section 12.8 for privacy considerations on status types.¶

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 implicitly or out-of-band.¶

A successful response that contains a Status List Token MUST use an HTTP status code in the 2xx range.¶

A response MAY also choose to redirect the client to another URI using an HTTP status code in the 3xx range, which clients SHOULD follow. A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).¶

The following are non-normative examples of 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.-bnvYY-t7smPXMU87krNWSB7i4t-IJ3OOwvpljf9cmxLN7ue-DvX
jDwjOzClGDcl8YNf3NVnkxteSYACkWVAug

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].¶

If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior.¶

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 and expiration time. The processing rules for Referenced Tokens (such as 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 for this document, this validation is not described here, but is expected to be done according to the format of the Referenced Token.¶

If this validation is 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 JOSE-based Referenced Tokens and Section 6.3 for COSE-based Referenced Tokens. Other formats of Referenced Tokens may define other encoding of the URI and index.¶

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. This step might require the resolution of a public key as described in Section 11.3.¶

   2. Check for the existence of the required claims as defined in Section 5.1 and Section 5.2 depending on the 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 the 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 bounds 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 of 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 of a response for the above Request:¶

HTTP/1.1 200 OK
Content-Type: application/statuslist+jwt

eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e
yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
nR0bCI6NDMyMDB9.-bnvYY-t7smPXMU87krNWSB7i4t-IJ3OOwvpljf9cmxLN7ue-DvX
jDwjOzClGDcl8YNf3NVnkxteSYACkWVAug

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. If the Issuer is an OAuth Authorization Server according to [RFC6749], it is RECOMMENDED to use status_list_aggregation_endpoint for its metadata defined by [RFC8414].¶

The 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 in Section 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.1. Extended Key Usage Extension

[RFC5280] specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used.¶

The following OID is defined for usage in the EKU extension¶

``` id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }¶

id-kp-oauthStatusListSigning OBJECT IDENTIFIER ::= { id-kp TBD } ```¶

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 right). 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. Key Resolution and Trust Management

This specification does not mandate specific methods for key resolution and trust management, however the following recommendations are made:¶

If the Issuer of the Referenced Token is the same entity as the Status Issuer, then the same key that is embedded into the Referenced Token may be used for the Status List Token. In this case the Status List Token may use: - the same x5c value or an x5t, x5t#S256 or kid parameter referencing to the same key as used in the Referenced Token for JOSE. - the same x5chain value or an x5t or kid parameter referencing to the same key as used in the Referenced Token for COSE.¶

Alternatively, the Status Issuer may use the same web-based key resolution that is used for the Referenced Token. In this case the Status List Token may use: - an x5u, jwks, jwks_uri or kid parameter referencing to a key using the same web-based resolution as used in the Referenced Token for JOSE. - an x5u or kid parameter referencing to a key using the same web-based resolution as used in the Referenced Token for COSE.¶

┌────────┐  host keys  ┌──────────────────────┐
│ Issuer ├────────┬───►│ .well-known metadata │
└─┬──────┘        │    └──────────────────────┘
  ▼ update status │
┌───────────────┐ │
│ Status Issuer ├─┘
└─┬─────────────┘
  ▼ provide Status List
┌─────────────────┐
│ Status Provider │
└─────────────────┘

If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by an Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize extended key usage (Section 10.1).¶

┌───────────────────────┐
│ Certificate Authority │
└─┬─────────────────────┘
  │ authorize
  │  ┌────────┐
  ├─►│ Issuer │
  │  └─┬──────┘
  │    ▼ update status
  │  ┌───────────────┐
  └─►│ Status Issuer │
     └─┬─────────────┘
       ▼ provide Status List
     ┌─────────────────┐
     │ Status Provider │
     └─────────────────┘

11.4. Status List Caching

When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for. Collectively the iat, exp and ttl claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for. The following diagram illustrates the relationship between these claims and how they are designed to influence caching.¶

Time of fetching

         │
         │            Check for        Check for        Check for
         │             updates          updates          updates
         │
 iat     │                │                │                │    exp
         │                │                │                │
  │      │                │                │                │     │
  │      │                │                │                │     │
  │      │                │                │                │     │
  │      │                │                │                │     │
  │      │      ttl       │      ttl       │      ttl       │     │
  │      │ ─────────────► │ ─────────────► │ ─────────────► │ ──► │
  │      │                │                │                │     │
  │      │                │                │                │     │
  │                                                               │
──┼───────────────────────────────────────────────────────────────┼─►
  │                                                               │

It is essential to understand the distinct purposes of the ttl and exp claims. The ttl claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the exp claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer. Together, these claims provide guidance on when to check for updates (ttl claim) and when the Status List must be refreshed or replaced (exp claim).¶

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 mechanisms 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 them 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

The tuple of uri and index inside the Referenced Token are unique and therefore is traceable data.¶

12.6. External Status Provider for Privacy

If the roles of the Status Issuer and the Status Provider are performed by 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, while still ensuring authenticity and integrity of Token Status List, as it is signed by the Status Issuer.¶

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 consideration 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.¶

12.8. Status Types

As previously explained, there is the potential risk of observability by Relying Parties (see Section 12.3) and Outsiders (see Section 12.4). That means that any Status Type that transports special information about a Token can leak information to other parties. This documents defines one additional Status Type with "SUSPENDED" that conveys such additional information. Depending on the use-case, suspended could for example provide information that an authorization in the Token is suspended, but the token itself is still valid.¶

A concrete example would be a driver's license, where the digital driver's license might still be useful to prove other information about its holder, but suspended could signal that it should not be considered valid in the scope of being allowed to drive a car. This case could be solved by either introducing a special status type, or by revoking the Token and re-issuing with changed attributes. For such a case, the status type suspended might be dangerous as it would leak the information of a suspended driver's license even if the driver's license is used as a mean of identification and not in the context of driving a car. This could also allow for the unwanted collection of statistical data on the status of driver's licenses.¶

Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re-issuance might a better fit for their use-case.¶

13.1. Referenced 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 the 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 from becoming a 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 storage and transmission size of the Status Issuer's Status List Tokens depends on: - the size of the Status List, i.e. the number of Referenced Tokens - the revocation rate and distribution of the Status List data (due to compression, revocation rates close to 0% or 100% create lowest sizes while revocation rates closer to 50% and random distribution create highest sizes) - the lifetime of Referenced Tokens (shorter lifetimes allows for earlier retirement of Status List Tokens)¶

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. The Status List Issuer may chunk the Status List Tokens depending on the Referenced Token's expiry date to align their lifecycles and allow for easier retiring of Status List Tokens, however the Status Issuer must be aware of possible privacy risks due to correlations.¶

13.4. External Status Issuer

If the roles of the Issuer of the Referenced Token and the Status Issuer are performed by different entities, this may allow for use case that require revocations of Referenced Tokens to be managed by a different entities, e.g. for regulatory or privacy reasons. In this scenario both parties must align on:¶

• the key and trust management as described in Section 11.3¶

• parameters for the Status List¶

  • number of bits for the Status Type as described in Section 4¶

  • update cycle of the Issuer used for ttl in the Status List Token as described in Section 5¶

13.5. External Status Provider for Scalability

If the roles of the Status Issuer and the Status Provider are performed by different entities, this may allow for greater scalability, as the Status List Tokens may be served by operators with greater resources, like CDNs. At the same time the authenticity and integrity of Token Status List is still guaranteed, as it is signed by the Status Issuer.¶

13.6. Relying Parties avoiding correlatable Information

If the Relying Party does not require the Referenced Token and the Status List Token after the presentation, e.g. for subsequent status checks or audit trail, it is RECOMMENDED to delete correlatable information, in particular:¶

• the status claim in the Referenced Token¶

• the Status List Token itself¶

The Relying Party should instead only keep the relevant payload from the Referenced Token.¶

13.7. 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.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.2. JWT Status Mechanisms Registry

This specification establishes the IANA "JWT Status Mechanisms" registry for JWT "status" member values and adds it to the "JSON Web Token (JWT)" registry group at https://www.iana.org/assignments/jwt. The registry records the status mechanism member and a reference to the specification that defines it.¶

JWT Status Mechanisms are registered by Specification Required [RFC5226] after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.¶

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWT Status Mechanism: example").¶

Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.¶

IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.¶

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.4. CWT Status Mechanisms Registry

This specification establishes the IANA "CWT Status Mechanisms" registry for CWT "status" member values and adds it to the "CBOR Web Token (CWT) Claims" registry group at https://www.iana.org/assignments/cwt. The registry records the status mechanism member and a reference to the specification that defines it.¶

CWT Status Mechanisms are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.¶

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism: example").¶

Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.¶

IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.¶

14.5. OAuth Status Types Registry

This specification establishes the IANA "OAuth Status Types" registry for Status List values and adds it to the "OAuth Parameters" registry group at https://www.iana.org/assignments/oauth-parameters. The registry records a human readable label, the bit representation and a common description for it.¶

Status Types are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.¶

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Status Type name: example").¶

Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.¶

IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.¶

14.6. OAuth Parameters Registration

This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Params] established by [RFC8414].¶

• Metadata Name: status_list_aggregation_endpoint¶

• Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management.¶

• Change Controller: IETF¶

• Reference: Section 9 of this specification¶

14.7. 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¶

14.8. X.509 Certificate Extended Key Purpose OID Registration

IANA is also requested to register the following OID "1.3.6.1.5.5.7.3.TBD" in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3), this OID is defined in section Section 10.1.¶

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

[IANA.OAuth.Params]

IANA, "OAuth Authorization Server Metadata", n.d., <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata>.

[RFC1950]

Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, <https://www.rfc-editor.org/rfc/rfc1950>.

[RFC1951]

Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <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, November 1996, <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, March 1997, <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, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5226]

Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/rfc/rfc5226>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <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, May 2015, <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, May 2015, <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, May 2017, <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, December 2017, <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, May 2018, <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, February 2020, <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, December 2020, <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, August 2022, <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, June 2022, <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, June 2024, <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, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <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, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC9458]

Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, <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-08, 3 December 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-08>.

[smith2020let]

Smith, T., Dickinson, L., and K. Seamons, "Let's revoke: Scalable global certificate revocation", Network and Distributed Systems Security (NDSS) Symposium 2020 , n.d., <https://www.ndss-symposium.org/ndss-paper/lets-revoke-scalable-global-certificate-revocation/>.

[W3C.SL]

Longley, D., Sporny, M., and O. Steele, "W3C Bitstring Status List v1.0", December 2024, <https://www.w3.org/TR/vc-bitstring-status-list/>.

1 bit Status List

The following example uses a 1 bit Status List (2 possible values):¶

status[0]=1
status[1993]=1
status[25460]=1
status[159495]=1
status[495669]=1
status[554353]=1
status[645645]=1
status[723232]=1
status[854545]=1
status[934534]=1
status[1000345]=1

JSON encoding:¶

{
  "bits": 1,
  "lst": "eNrt3AENwCAMAEGogklACtKQPg9LugC9k_ACvreiogE
  AAKkeCQAAAAAAAAAAAAAAAAAAAIBylgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAXG9IAAAAAAAAAPwsJAAAAAAAAAAAAAAAvhsSAAAAAAAAAAA
  A7KpLAAAAAAAAAAAAAAAAAAAAAJsLCQAAAAAAAAAAADjelAAAAAAAAAAAKjDMAQAAA
  ACAZC8L2AEb"
}

CBOR encoding:¶

a2646269747301636c737458bd78daeddc010dc0200c0041a88249400ad2903e0f4b
ba00bd93f002beb7a2a2010000a91e09000000000000000000000000000000807296
04000000000000000000000000000000000000000000000000000000000000000000
000000000000005c6f4800000000000000fc2c240000000000000000000000be1b12
000000000000000000ecaa4b000000000000000000000000000000009b0b09000000
00000000000038de9400000000000000002a30cc010000000080642f0bd8011b

2 bit Status List

The following example uses a 2 bit Status List (4 possible values):¶

status[0]=1
status[1993]=2
status[25460]=1
status[159495]=3
status[495669]=1
status[554353]=1
status[645645]=2
status[723232]=1
status[854545]=1
status[934534]=2
status[1000345]=3

JSON encoding:¶

{
  "bits": 2,
  "lst": "eNrt2zENACEQAEEuoaBABP5VIO01fCjIHTMStt9ovGV
  IAAAAAABAbiEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEB5WwIAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAID0ugQAAAAAAAAAAAAAAAAAQG12SgAAA
  AAAAAAAAAAAAAAAAAAAAAAAAOCSIQEAAAAAAAAAAAAAAAAAAAAAAAD8ExIAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwJEuAQAAAAAAAAAAAAAAAAAAAAAAAMB9S
  wIAAAAAAAAAAAAAAAAAAACoYUoAAAAAAAAAAAAAAEBqH81gAQw"
}

CBOR encoding:¶

a2646269747302636c737459013d78daeddb310d00211000412ea1a04004fe5520ed
357c28c81d3312b6df68bc65480000000000406e2101000000000000000000000000
0000000000000000000000000000000000000040795b020000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
0080f4ba0400000000000000000000000000406d764a000000000000000000000000
000000000000000000e0922101000000000000000000000000000000000000fc1312
00000000000000000000000000000000000000000000000000000000000000c0912e
01000000000000000000000000000000000000c07d4b020000000000000000000000
00000000a8614a0000000000000000000000406a1fcd60010c

4 bit Status List

The following example uses a 4 bit Status List (16 possible values):¶

status[0]=1
status[1993]=2
status[35460]=3
status[459495]=4
status[595669]=5
status[754353]=6
status[845645]=7
status[923232]=8
status[924445]=9
status[934534]=10
status[1004534]=11
status[1000345]=12
status[1030203]=13
status[1030204]=14
status[1030205]=15

JSON encoding:¶

{
  "bits": 4,
  "lst": "eNrt0EENgDAQADAIHwImkIIEJEwCUpCEBBQRHOy35Li
  1EjoOQGabAgAAAAAAAAAAAAAAAAAAACC1SQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABADrsCAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAADoxaEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIIoCgAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACArpwKAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAGhqVkAzlwIAAAAAiGVRAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAAAAAAAAAAABx3AoAgLpVAQAAAAAAAAAAAAAAwM89rwMAAAAAAAAAA
  AjsA9xMBMA"
}

CBOR encoding:¶

a2646269747304636c737459024878daedd0410d8030100030081f0226908204244c
025290840414111cecb7e4b8b5123a0e40669b020000000000000000000000000000
0020b549010000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
0000000000400ebb0200000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
000000000000e8c5a100000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000082280a00000000000000000000000000
00000000000000000000000000000000000000000000000000000000000080ae9c0a
00000000000000000000000000000000000000000000000000000000000000000000
000000686a5640339702000000008865510000000000000000000000000000000000
00000000000000000000000000000071dc0a0080ba55010000000000000000000000
c0cf3daf03000000000000000008ec03dc4c04c0

8 bit Status List

The following example uses a 8 bit Status List (256 possible values):¶

status[233478] = 0
status[52451] = 1
status[576778] = 2
status[513575] = 3
status[468106] = 4
status[292632] = 5
status[214947] = 6
status[182323] = 7
status[884834] = 8
status[66653] = 9
status[62489] = 10
status[196493] = 11
status[458517] = 12
status[487925] = 13
status[55649] = 14
status[416992] = 15
status[879796] = 16
status[462297] = 17
status[942059] = 18
status[583408] = 19
status[13628] = 20
status[334829] = 21
status[886286] = 22
status[713557] = 23
status[582738] = 24
status[326064] = 25
status[451545] = 26
status[705889] = 27
status[214350] = 28
status[194502] = 29
status[796765] = 30
status[202828] = 31
status[752834] = 32
status[721327] = 33
status[554740] = 34
status[91122] = 35
status[963483] = 36
status[261779] = 37
status[793844] = 38
status[165255] = 39
status[614839] = 40
status[758403] = 41
status[403258] = 42
status[145867] = 43
status[96100] = 44
status[477937] = 45
status[606890] = 46
status[167335] = 47
status[488197] = 48
status[211815] = 49
status[797182] = 50
status[582952] = 51
status[950870] = 52
status[765108] = 53
status[341110] = 54
status[776325] = 55
status[745056] = 56
status[439368] = 57
status[559893] = 58
status[149741] = 59
status[358903] = 60
status[513405] = 61
status[342679] = 62
status[969429] = 63
status[795775] = 64
status[566121] = 65
status[460566] = 66
status[680070] = 67
status[117310] = 68
status[480348] = 69
status[67319] = 70
status[661552] = 71
status[841303] = 72
status[561493] = 73
status[138807] = 74
status[442463] = 75
status[659927] = 76
status[445910] = 77
status[1046963] = 78
status[829700] = 79
status[962282] = 80
status[299623] = 81
status[555493] = 82
status[292826] = 83
status[517215] = 84
status[551009] = 85
status[898490] = 86
status[837603] = 87
status[759161] = 88
status[459948] = 89
status[290102] = 90
status[1034977] = 91
status[190650] = 92
status[98810] = 93
status[229950] = 94
status[320531] = 95
status[335506] = 96
status[885333] = 97
status[133227] = 98
status[806915] = 99
status[800313] = 100
status[981571] = 101
status[527253] = 102
status[24077] = 103
status[240232] = 104
status[559572] = 105
status[713399] = 106
status[233941] = 107
status[615514] = 108
status[911768] = 109
status[331680] = 110
status[951527] = 111
status[6805] = 112
status[552366] = 113
status[374660] = 114
status[223159] = 115
status[625884] = 116
status[417146] = 117
status[320527] = 118
status[784154] = 119
status[338792] = 120
status[1199] = 121
status[679804] = 122
status[1024680] = 123
status[40845] = 124
status[234603] = 125
status[761225] = 126
status[644903] = 127
status[502167] = 128
status[121477] = 129
status[505144] = 130
status[165165] = 131
status[179628] = 132
status[1019195] = 133
status[145149] = 134
status[263738] = 135
status[269256] = 136
status[996739] = 137
status[346296] = 138
status[555864] = 139
status[887384] = 140
status[444173] = 141
status[421844] = 142
status[653716] = 143
status[836747] = 144
status[783119] = 145
status[918762] = 146
status[946835] = 147
status[253764] = 148
status[519895] = 149
status[471224] = 150
status[134272] = 151
status[709016] = 152
status[44112] = 153
status[482585] = 154
status[461829] = 155
status[15080] = 156
status[148883] = 157
status[123467] = 158
status[480125] = 159
status[141348] = 160
status[65877] = 161
status[692958] = 162
status[148598] = 163
status[499131] = 164
status[584009] = 165
status[1017987] = 166
status[449287] = 167
status[277478] = 168
status[991262] = 169
status[509602] = 170
status[991896] = 171
status[853666] = 172
status[399318] = 173
status[197815] = 174
status[203278] = 175
status[903979] = 176
status[743015] = 177
status[888308] = 178
status[862143] = 179
status[979421] = 180
status[113605] = 181
status[206397] = 182
status[127113] = 183
status[844358] = 184
status[711569] = 185
status[229153] = 186
status[521470] = 187
status[401793] = 188
status[398896] = 189
status[940810] = 190
status[293983] = 191
status[884749] = 192
status[384802] = 193
status[584151] = 194
status[970201] = 195
status[523882] = 196
status[158093] = 197
status[929312] = 198
status[205329] = 199
status[106091] = 200
status[30949] = 201
status[195586] = 202
status[495723] = 203
status[348779] = 204
status[852312] = 205
status[1018463] = 206
status[1009481] = 207
status[448260] = 208
status[841042] = 209
status[122967] = 210
status[345269] = 211
status[794764] = 212
status[4520] = 213
status[818773] = 214
status[556171] = 215
status[954221] = 216
status[598210] = 217
status[887110] = 218
status[1020623] = 219
status[324632] = 220
status[398244] = 221
status[622241] = 222
status[456551] = 223
status[122648] = 224
status[127837] = 225
status[657676] = 226
status[119884] = 227
status[105156] = 228
status[999897] = 229
status[330160] = 230
status[119285] = 231
status[168005] = 232
status[389703] = 233
status[143699] = 234
status[142524] = 235
status[493258] = 236
status[846778] = 237
status[251420] = 238
status[516351] = 239
status[83344] = 240
status[171931] = 241
status[879178] = 242
status[663475] = 243
status[546865] = 244
status[428362] = 245
status[658891] = 246
status[500560] = 247
status[557034] = 248
status[830023] = 249
status[274471] = 250
status[629139] = 251
status[958869] = 252
status[663071] = 253
status[152133] = 254
status[19535] = 255

JSON encoding:¶

{
  "bits": 8,
  "lst": "eNrt0WOQM2kYhtGsbdu2bdu2bdu2bdu2bdu2jVnU1my
  -SWYm6U5enFPVf7ue97orFYAo7CQBAACQuuckAABStqUEAAAAAAAAtN6wEgAE71QJA
  AAAAIrwhwQAAAAAAdtAAgAAAAAAACLwkAQAAAAAAAAAAACUaFcJAACAeJwkAQAAAAA
  AAABQvL4kAAAAWmJwCQAAAAAAAAjAwBIAAAB06ywJoDKQBARpfgkAAAAAAAAAAAAAA
  AAAAACo50sJAAAAAAAAAOiRcSQAAAAAgAJNKgEAAG23mgQAAAAAAECw3pUAQvegBAA
  AAAAAAADduE4CAAAAyjSvBAAQiw8koHjvSABAb-wlARCONyVoxtMSZOd0CQAAAOjWD
  RKQmLckAAAAAACysLYEQGcnSAAAAAAQooUlAABI15kSAIH5RAIgLB9LABC4_SUgGZN
  IAABAmM6RoLbTJIASzCIBAEAhfpcAAAAAAABquk8CAAAAAAAAaJl9SvvzBOICAFWmk
  IBgfSgBAAAANOgrCQAAAAAAAADStK8EAAC03gASAAAAAAAAAADFWFUCAAAAMjOaBEA
  DHpYAQjCIBADduFwCAAAAAGitMSSI3BUSAECOHpAA6IHrJQAAAAAAsjeVBAAAKRpVA
  orWvwQAAAAAAAAAkKRtJAAAAAAAgCbcLAF0bXUJAAAAoF02kYDg7CYBAAAAAEB6NpQ
  AAAAAAAAAAAAAAEr1uQQAAF06VgIAAAAAAAAAqDaeBAAQqgMkAAAAAABogQMlAAAAA
  AAa87MEAAAQiwslAAAAAAAAAAAAAAAAMrOyBAAAiekv-hcsY0Sgne6QAAAAAAAgaUt
  JAAAAAAAAAAAAAAAAAAAAAAAAAADwt-07vjVkAAAAgDy8KgFAUEaSAAAAAJL3vgQAW
  dhcAgAAoBHDSUDo1pQAAACI2o4SAABZm14CALoyuwQAAPznGQkgZwdLAAAQukclAAA
  AAAAAAAAAgKbMKgEAAAAAAAAAAAAAAAAAAECftpYAAAAAAAAAAAAACnaXBAAAAADk7
  iMJAAAAAAAAAABqe00CAnGbBBG4TAIAgFDdKgFAXCaWAAAAAAAAAAAAAAAAAKAJQwR
  72XbGAQAAAKAhh0sAAAAAAABQgO8kAAAAAAAAAAAAACAaM0kAAAC5W0QCAIJ3mAQAx
  GwxCQAA6nhSAsjZBRIAANEbWQIAAAAAaJE3JACAwA0qAUBIVpKAlphbAiAPp0iQnKE
  kAAAAAAAgBP1KAAAAdOl4CQAAAAAAAPjLZBIAAG10RtrPm8_CAEBMTpYAAAAAAIjQY
  BL8z5QSAAAAAEDYPpUAACAsj0gAAADQkHMlAAjHDxIA0Lg9JQAAgHDsLQEAAABAQS6
  WAAAAgLjNFs2l_RgLAIAEfCEBlGZZCQAAaIHjJACgtlskAAAozb0SAAAAVFtfAgAAA
  AAAAAAAAAAAAAAAAAAAAKDDtxIAAAAAVZaTAKB5W0kAANCAsSUgJ0tL0GqHSNBbL0g
  AZflRAgCARG0kQXNmlgCABiwkAQAAAEB25pIAAAAAAAAAAAAAoFh9SwAAAAAAADWNm
  OSrpjFsEoaRgDKcF9Q1dxsEAAAAAAAAAAAAAAAAgPZ6SQIAAAAAAAAAgChMLgEAAAA
  AAAAAqZlQAsK2qQQAAAAAAAD06XUJAAAAqG9bCQAAgLD9IgEAAAAAAAAAAAAAAAAAA
  EBNe0gAAAAAAAAAAEBPHSEBAAAAlOZtCYA4fS8B0GFRCQAo0gISAOTgNwmC840EAAA
  AAAAAAAAAAAAAAAAAUJydJfjXPBIAAAAAAAAAAAAAAABk6WwJAAAAAAAAAAAAAAAAq
  G8UCQAAgPpOlAAAIA83SQAANWwc9HUjGAgAAAAAAACAusaSAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAqHKVBACQjxklAAAAAAAAAKBHxpQAAAAAACBME0lAdlaUAACyt7sEAAAA0
  Nl0EgAAAAAAAAAAAABA-8wgAQAAAAAAAKU4SgKgUtlBAgAAAAAAAAAAgMCMLwEE51k
  JICdzSgCJGl2CsE0tAQAA0L11JQAAAAAAAAjUOhIAAAAAAAAAAAAAAGTqeQkAAAAAA
  AAAAAAAKM8SEjTrJwkAAAAAAACocqQEULgVJAAAACjDUxJUKgtKAAAAqbpRAgCA0n0
  mAQAAAABAGzwmAUCTLpUAAAAAAAAAAEjZNRIAAAAAAAAAAAAAAAAAAAAA8I-vJaAlh
  pQAAAAAAHrvzjJ-OqCuuVlLAojP8BJAr70sQZVDJYAgXS0BAAAAAAAAAAAAtMnyEgA
  AAAAAFONKCQAAAAAAAADorc0kAAAAAAAAgDqOlgAAAAAAAAAAAADIwv0SAAAAAAAAA
  AAAAADBuV0CIFVDSwAAAABAAI6RAAAAAGIwrQSEZAsJAABouRclAAAAAKDDrxIAAAA
  0bkkJgFiMKwEAAAAAAHQyhwRk7h4JAAAAAAAAAAAgatdKAACUYj0JAAAAAAAAAAAAQ
  nORBLTFJRIAAAAAkIaDJAAAAJryngQAAAAAAAAAAAA98oQEAAAAAAAAAEC2zpcgWY9
  LQKL2kwAgGK9IAAAAAPHaRQIAAAAAAAAAAADIxyoSAAAAAAAAAAAAAADQFotLAECz_
  gQ1PX-B"
}

CBOR encoding:¶

a2646269747308636c73745907b078daedd1639033691886d1ac6ddbb66ddbb66ddb
b66ddbb66ddbb68d59d4d66cbe496626e94e5e9c53d57fbb9ef7ba2b158028ec2401
000090bae724000052b6a504000000000000b4deb0120004ef5409000000008af087
040000000001db400200000000000022f09004000000000000000000946857090000
80789c24010000000000000050bcbe240000005a62700900000000000008c0c01200
000074eb2c09a032900404697e09000000000000000000000000000000a8e74b0900
000000000000e89171240000000080024d2a0100006db79a04000000000040b0de95
0042f7a00400000000000000ddb84e02000000ca34af0400108b0f24a078ef480040
6fec2501108e372568c6d31264e77409000000e8d60d129098b7240000000000b2b0
b604406727480000000010a28525000048d799120081f94402202c1f4b0010b8fd25
2019934800004098ce91a0b6d3248012cc22010040217e970000000000006aba4f02
00000000000068997d4afbf304e2020055a69080607d280100000034e82b09000000
00000000d2b4af040000b4de00120000000000000000c558550200000032339a0440
031e96004230880400ddb85c020000000068ad312488dc151200408e1e9000e881eb
250000000000b23795040000291a55028ad6bf040000000000000090a46d24000000
00008026dc2c01746d7509000000a05d369180e0ec260100000000407a3694000000
00000000000000004af5b90400005d3a560200000000000000a8369e040010aa0324
00000000006881032500000000001af3b3040000108b0b2500000000000000000000
000032b3b204000089e92ffa172c6344a09dee90000000000020694b490000000000
000000000000000000000000000000f0b7ed3bbe3564000000803cbc2a0140504692
0000000092f7be040059d85c020000a011c34940e8d69400000088da8e120000599b
5e0200ba32bb040000fce719092067074b000010ba472500000000000000000080a6
cc2a010000000000000000000000000000409fb696000000000000000000000a7697
0400000000e4ee230900000000000000006a7b4d0202719b0411b84c02008050dd2a
01405c269600000000000000000000000000a00943047bd976c601000000a021874b
0000000000005080ef2400000000000000000000201a3349000000b95b4402008277
980400c46c31090000ea785202c8d905120000d11b590200000000689137240080c0
0d2a01404856928096985b02200fa748909ca12400000000002004fd4a00000074e9
7809000000000000f8cb641200006d7446dacf9bcfc200404c4e96000000000088d0
6012fccf94120000000040d83e950000202c8f48000000d09073250008c70f1200d0
b83d2500008070ec2d0100000040412e9600000080b8cd16cda5fd180b0080047c21
019466590900006881e32400a0b65b24000028cdbd12000000545b5f020000000000
00000000000000000000000000a0c3b7120000000055969300a0795b490000d080b1
2520274b4bd06a8748d05b2f480065f951020080446d24417366960080062c240100
00004076e69200000000000000000000a0587d4b000000000000358d98e4aba6316c
12869180329c17d435771b0400000000000000000000000080f67a49020000000000
000080284c2e0100000000000000a9995002c2b6a904000000000000f4e975090000
00a86f5b09000080b0fd22010000000000000000000000000000404d7b4800000000
00000000404f1d210100000094e66d0980387d2f01d06151090028d2021200e4e037
0982f38d04000000000000000000000000000000509c9d25f8d73c12000000000000
00000000000064e96c09000000000000000000000000a86f1409000080fa4e940000
200f37490000356c1cf47523180800000000000080bac69200000000000000000000
0000000000000000000000a872950400908f192500000000000000a047c694000000
0000204c1349407656940000b2b7bb04000000d0d974120000000000000000000040
fbcc2001000000000000a5384a02a052d94102000000000000000080c08c2f0104e7
59092027734a00891a5d82b04d2d010000d0bd752500000000000008d43a12000000
000000000000000064ea79090000000000000000000028cf121234eb270900000000
0000a872a40450b8152400000028c35312542a0b4a000000a9ba51020080d27d2601
00000000401b3c260140932e95000000000000000048d93512000000000000000000
00000000000000f08faf25a025869400000000007aefce327e3aa0aeb9594b0288cf
f01240afbd2c4195432580205d2d01000000000000000000b4c9f212000000000014
e34a0900000000000000e8adcd24000000000000803a8e9600000000000000000000
c8c2fd120000000000000000000000c1b95d022055434b0000000040008e91000000
006230ad0484640b09000068b9172500000000a0c3af12000000346e490980588c2b
0100000000007432870464ee1e090000000000000000206ad74a000094623d090000
0000000000000042739104b4c5251200000000908683240000009af29e0400000000
00000000003df284040000000000000040b6ce9720598f4b40a2f693002018af4800
000000f1da4502000000000000000000c8c72a120000000000000000000000d0168b
4b0040b3fe04353d7f81