| Internet-Draft | Token Status List | October 2024 |
| Looker, et al. | Expires 5 April 2025 | [Page] |
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. The status list token data structures themselves are also represented as JWTs or CWTs.¶
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.¶
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 5 April 2025.¶
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.¶
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 JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided via HTTPS or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The document also defines how an issuer of a Referenced Token references a Status List (Token).¶
An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of [RFC6749]. Token Introspection [RFC7662] defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation.¶
Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model [SD-JWT.VC]. The following diagram depicts the basic conceptual relationship.¶
+-------------------+ +------------------------+
| | describes status | |
| Status List +----------------->| Referenced Token |
| (JSON or CBOR) <------------------+ (JOSE, COSE) |
| | references | |
+-------+-----------+ +--------+---------------+
|
|embedded in
v
+-------------------+
| |
| Status List Token |
| (JWT or CWT) |
| |
+-------------------+
¶
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 Issuer.¶
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.¶
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¶
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.¶
An entity that issues the Referenced Token and provides the status information of the Referenced Token by serving a Status List Token on a public endpoint.¶
An entity that relies on the Status List to validate the status of the Referenced Token. Also known as Verifier.¶
An object in JSON or CBOR representation containing a bit array that lists the statuses of many Referenced Tokens.¶
A token in JWT or CWT representation that contains a cryptographically secured Status List.¶
A cryptographically secured data structure which contains a reference to a Status List or Status List Token. It is RECOMMENDED to use JSON [RFC8259] or CBOR [RFC8949] for representation of the token and secure it using JSON Object Signing as defined in [RFC7515] or CBOR Object Signing and Encryption as defined in [RFC9052]. The information from the contained Status List may give a Relying Party additional information about up-to-date status of the Referenced Token.¶
Denotes the URL-safe base64 encoding without padding as defined in Section 2 of [RFC7515] as "Base64url Encoding".¶
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:¶
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.¶
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.¶
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
¶
This section defines the 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"
}
¶
This section defines the structure for a CBOR-encoded Status List:¶
The StatusList structure is a map (Major Type 5) and defines the following entries:¶
bits: REQUIRED. Unsigned int (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]"
¶
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.¶
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. 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. The iat (issued at) claim MUST specify the time at which the Status List Token was issued.¶
exp: OPTIONAL. The exp (expiration time) claim, if present, MUST specify the time at which the Status List Token is considered expired by its 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.¶
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:¶
The JWT MAY contain other claims.¶
The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm. Relying parties MUST reject JWTs with an invalid signature.¶
Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" [RFC7519].¶
Application of additional restrictions and policy are at the discretion of the verifying 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
}
¶
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:¶
The following content applies to the CWT Claims Set:¶
2 (subject): REQUIRED. Same definition as sub claim in Section 5.1.¶
6 (issued at): REQUIRED. Same definition as iat claim in Section 5.1.¶
4 (expiration time): OPTIONAL. Same definition as exp claim in Section 5.1.¶
65534 (time to live): OPTIONAL. Same definition as ttl claim in Section 5.1.¶
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:¶
The CWT MAY contain other claims.¶
The CWT MUST be digitally signed using an asymmetric cryptographic algorithm. Relying parties MUST reject the CWT if it is using a Message Authentication Code (MAC) algorithm. Relying parties MUST reject CWTs with an invalid signature.¶
Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" [RFC8392].¶
Application of additional restrictions and policy are at the discretion of the verifying party.¶
The following is a non-normative example for a Status List Token in CWT format in Hex:¶
d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a 648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb b918000217015d584003d2aeb1c53cb6f5486a26f9767b60475cef6f3f9589e79f48 038a3c2c3dbe8cbce1095f4898cfe4f38af8fc6337f7d8d1be8705d71cca5c57be93 79ae96d227¶
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)
03d2aeb1c53cb6f5486a26f9 # "\x03Ò®±Å<¶õHj&ù"
767b60475cef6f3f9589e79f # "v{`G\ïo?\x95\x89ç\x9f"
48038a3c2c3dbe8cbce1095f # "H\x03\x8a<,=¾\x8c¼á\x09_"
4898cfe4f38af8fc6337f7d8 # "H\x98Ïäó\x8aøüc7÷Ø"
d1be8705d71cca5c57be9379 # "Ѿ\x87\x05×\x1cÊ\W¾\x93y"
ae96d227 # "®\x96Ò'"
¶
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 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.¶
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 list mechanism defined in this specification is used. It contains a reference to a Status List or 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 or 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 verifying 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 List 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"
}
¶
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 list 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. Same definition as idx claim in Section 6.2.¶
uri: REQUIRED. Same definition as uri claim in Section 6.2.¶
Application of additional restrictions and policy are at the discretion of the verifying party.¶
The following is a non-normative example of a Referenced Token in CWT format in Hex:¶
d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f 7374617475736c697374732f3158409e46484865d84adfbaa4f26e541fa6b3e49e1a 40bcd33117f810a5a37f8b44dee85188ac504b7bc6e404bac830cba4b28197abe1d4 9bca21c88b0c2c28749c94¶
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)
9e46484865d84adfbaa4f26e # "\x9eFHHeØJߺ¤òn"
541fa6b3e49e1a40bcd33117 # "T\x1f¦³ä\x9e\x1a@¼Ó1\x17"
f810a5a37f8b44dee85188ac # "ø\x10¥£\x7f\x8bDÞèQ\x88¬"
504b7bc6e404bac830cba4b2 # "PK{Æä\x04ºÈ0ˤ²"
8197abe1d49bca21c88b0c2c # "\x81\x97«áÔ\x9bÊ!È\x8b\x0c,"
28749c94 # "(t\x9c\x94"
¶
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 verifying 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'
]
¶
This document defines potential statuses of Referenced Tokens as Status Type values. 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. A Status List can not represent multiple statuses per Referenced Token.¶
The registry in this document describes the basic Status Type values required for the most common use cases. Additional values may defined for particular use cases.¶
A status describes the state, mode, condition or stage of an entity that is described by the Status List. Status Types MUST be numeric values between 0 and 255. Status types described by this specification comprise:¶
0x00 - "VALID" - The status of the Token is valid, correct or legal.¶
0x01 - "INVALID" - The status of the Token is revoked, annulled, taken back, recalled or cancelled. This state is irreversible.¶
0x02 - "SUSPENDED" - The status of the Token is temporarily invalid, hanging, debarred from privilege. This state is reversible.¶
The issuer of the Status List 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.¶
To obtain the Status List or Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token.¶
If the Status List is provided by an HTTP endpoint (and not as a Status List Token), the provider of the Status List MUST utilize TLS. Which version(s) should be implemented will vary over time. A TLS server certificate check MUST be performed as defined in Section 5 and 6 of [RFC6125].¶
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+json" for Status List in JSON format¶
"application/statuslist+jwt" for Status List in JWT format¶
"application/statuslist+cbor" for Status List in CBOR format¶
"application/statuslist+cwt" for Status List 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.¶
In the successful response, the Status List Provider MUST use the following content-type:¶
"application/statuslist+json" for Status List in JSON format¶
"application/statuslist+jwt" for Status List in JWT format¶
"application/statuslist+cbor" for Status List in CBOR format¶
"application/statuslist+cwt" for Status List in CWT format¶
In the case of "application/statuslist+json", the response MUST be of type JSON and follow the rules of Section 4.1. 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+cbor", the response MUST be of type CBOR and follow the rules of Section 4.2. 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].¶
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. 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:¶
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¶
Resolve the Status List from the provided URI¶
Validate the Status List Token:¶
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.¶
Check for the existence of the required claims as defined in Section 5.1 and Section 5.2¶
All existing claims in the Status List Token MUST be checked according to the rules in Section 5.1 and Section 5.2¶
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¶
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)¶
If expiration time is defined (exp or 4), it MUST be checked if the Status List Token is expired¶
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)¶
Decompress the Status List with a decompressor that is compatible with DEFLATE [RFC1951] and ZLIB [RFC1950]¶
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¶
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.¶
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.¶
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 issuer of the Referenced Token includes an additional claim in the Status List (Token) that contains the Status List Aggregation URI.¶
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.¶
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.¶
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"
]
}
¶
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"
}
¶
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.¶
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].¶
When consumers or verifiers of the Status List fetch the data, 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.¶
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].¶
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.¶
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.¶
TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture¶
This behaviour could be mitigated by: - regular re-issuance of the Referenced Token, see Section 13.1.¶
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 (TODO:link) - disable the Status List Aggregation {#batch-fetching} - 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¶
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:¶
TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possibilities TODO evaluate definition of Status List Provider? An entity that hosts the Status List as a resource for potential Relying Parties. The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party.¶
The lifetime of a Status List (and the 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 (and 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.¶
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.¶
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.¶
This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry [IANA.JWT] established by [RFC7519].¶
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¶
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.¶
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 Standards Track RFCs, list the "IESG". 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.¶
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¶
This specification requests registration of the following Claims in the IANA "CBOR Web Token (CWT) Claims" registry [IANA.CWT] established by [RFC8392].¶
Claim Name: status¶
Claim Key: TBD (requested assignment 65535)¶
Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.¶
Change Controller: IETF¶
Specification Document(s): Section 6.1 of this specification¶
Claim Name: status_list¶
Claim Key: TBD (requested assignment 65533)¶
Claim Description: A status list containing up-to-date status information on multiple tokens.¶
Change Controller: IETF¶
Specification Document(s): Section 5.2 of this specification¶
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.¶
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 Standards Track RFCs, list the "IESG". 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.¶
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¶
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 JSON-based Status List:¶
Type name: application¶
Subtype name: statuslist+json¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: See Section 4.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 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 CBOR-based Status List:¶
Type name: application¶
Subtype name: statuslist+cbor¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: See Section 4.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¶
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¶
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.¶
-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¶