Token Status List
draft-ietf-oauth-status-list-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Tobias Looker , Paul Bastian , Christian Bormann | ||
| Last updated | 2024-02-05 (Latest revision 2023-10-23) | ||
| Replaces | draft-looker-oauth-jwt-cwt-status-list | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART IETF Last Call review
(of
-13)
by Dale Worley
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-oauth-status-list-01
Network Working Group T. Looker
Internet-Draft MATTR
Intended status: Informational P. Bastian
Expires: 9 August 2024
C. Bormann
6 February 2024
Token Status List
draft-ietf-oauth-status-list-01
Abstract
This specification defines status list data structures for
representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR
Web Tokens (CWTs) [RFC8392]. The status list data structures
themselves are also represented as JWTs or CWTs.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://vcstuff.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/vcstuff/draft-ietf-oauth-status-list.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 August 2024.
Looker, et al. Expires 9 August 2024 [Page 1]
Internet-Draft Token Status List February 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Design Considerations . . . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Status List . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Status List in JSON Format . . . . . . . . . . . . . . . 7
4.2. Status List in CBOR Format . . . . . . . . . . . . . . . 8
5. Status List Token . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Status List Token in JWT Format . . . . . . . . . . . . . 8
5.2. Status List Token in CWT Format . . . . . . . . . . . . . 10
6. Referenced Token . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Status Claim . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Referenced Token in JWT Format . . . . . . . . . . . . . 10
6.3. Referenced Token in CWT/CBOR Format . . . . . . . . . . . 11
7. Status Types . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Status Types Values . . . . . . . . . . . . . . . . . . . 12
8. Verification and Processing . . . . . . . . . . . . . . . . . 12
8.1. Status List Request . . . . . . . . . . . . . . . . . . . 12
8.2. Status List Response . . . . . . . . . . . . . . . . . . 13
8.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Validation Rules . . . . . . . . . . . . . . . . . . . . 14
9. Further Examples . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Status List Token with 2-Bit Status Values in JWT
format . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Correct decoding and parsing of the encoded status
list . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Cached and Stale status lists . . . . . . . . . . . . . 15
10.3. Authorized access to the Status List . . . . . . . . . . 15
10.4. History . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
Looker, et al. Expires 9 August 2024 [Page 2]
Internet-Draft Token Status List February 2024
11.1. Issuer tracking and Herd Privacy . . . . . . . . . . . . 15
11.2. Malicious Issuers . . . . . . . . . . . . . . . . . . . 16
11.3. Relying Party tracking . . . . . . . . . . . . . . . . . 16
11.4. Correlation Risks and Tracking . . . . . . . . . . . . . 16
11.5. Third Party Hosting . . . . . . . . . . . . . . . . . . 17
12. Implementation Considerations . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13.1. JSON Web Token Claims Registration . . . . . . . . . . . 17
13.1.1. Registry Contents . . . . . . . . . . . . . . . . . 17
13.2. JWT Status Mechanism Methods Registry . . . . . . . . . 18
13.2.1. Registration Template . . . . . . . . . . . . . . . 18
13.2.2. Initial Registry Contents . . . . . . . . . . . . . 18
13.3. Media Type Registration . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
Document History . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]
as secure token formats, have vast possible applications. Some of
these applications can involve issuing a token whereby certain
semantics about the token can change over time, which are important
to be able to communicate to relying parties in an interoperable
manner, such as whether the token is considered invalidated or
suspended by its issuer.
This document defines a Status List and its representations in JSON
and CBOR formats that describe the individual statuses of multiple
Referenced Tokens, which themselves are JWTs or CWTs. The statuses
of all Referenced Tokens are conveyed via a bit array in the Status
List. Each Referenced Token is allocated an index during issuance
that represents its position within this bit array. The value of the
bit(s) at this index correspond to the Referenced Token's status. A
Status List may either be provided by an endpoint or be signed and
embedded into a Status List Token, whereas this document defines its
representations in JWT and CWT. Status Lists may be composed for
expressing a range of Status Types. This document defines basic
Status Types for the most common use cases as well as an
extensibility mechanism for custom Status Types. The document also
defines how an issuer of a Referenced Token references a Status List
(Token).
Looker, et al. Expires 9 August 2024 [Page 3]
Internet-Draft Token Status List February 2024
An example for the usage of a Status List is to manage the status of
issued access tokens as defined in section 1.4 of [RFC6749]. Token
Introspection [RFC7662] defines another way to determine the status
of an issued access token, but it requires the party trying to
validate an access tokens status to directly contact the token
issuer, whereas the mechanism defined in this specification does not
have this limitation.
Another possible use case for the Status List is to express the
status of verifiable credentials (Referenced Tokens) issued by an
issuer in the Issuer-Holder-Verifier model. The following diagram
depicts the basic conceptual relationship.
+-------------------+ +------------------------+
| | describes status | |
| Status List +----------------->| Referenced Token |
| (JSON or CBOR) <------------------+ (JWT or CWT) |
| | references | |
+-------+-----------+ +--------+---------------+
|
|embedded in
v
+-------------------+
| |
| Status List Token |
| (JWT or CWT) |
| |
+-------------------+
1.1. Rationale
Revocation mechanisms are an essential part for most identity
ecosystems. In the past, revocation of X.509 TLS certificates has
been proven difficult. Traditional certificate revocation lists
(CRLs) have limited scalability; Online Certificate Status Protocol
(OCSP) has additional privacy risks, since the client is leaking the
requested website to a third party. OCSP stapling is addressing some
of these problems at the cost of less up-to-date data. Modern
approaches use accumulator-based revocation registries and Zero-
Knowledge-Proofs to accommodate for this privacy gap, but face
scalability issues again.
Looker, et al. Expires 9 August 2024 [Page 4]
Internet-Draft Token Status List February 2024
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.
1.2. Design Considerations
The decisions taken in this specification aim to achieve the
following design goals:
* the specification shall favor a simple and easy to understand
concept
* the specification shall be easy, fast and secure to implement in
all major programming languages
* the specification shall be optimized to support the most common
use cases and avoid unnecessary complexity of corner cases
* the Status List shall scale up to millions of tokens to support
large scale government or enterprise use cases
* the Status List shall enable caching policies and offline support
* the specification shall support JSON and CBOR based tokens
* the specification shall not specify key resolution or trust
frameworks
* the specification shall design an extension point to convey
information about the status of a token that can be re-used by
other mechanisms
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Looker, et al. Expires 9 August 2024 [Page 5]
Internet-Draft Token Status List February 2024
3. Terminology
Issuer: 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.
Relying Party: An entity that relies on the Status List to validate
the status of the Referenced Token. Also known as Verifier.
Status List: An object in JSON or CBOR representation containing a
bit array that lists the statuses of many Referenced Tokens.
Status List Token: A token in JWT or CWT representation that
contains a cryptographically secured Status List.
Referenced Token: A token in JWT or CWT representation which
contains a reference to a Status List or Status List Token. The
information from the contained Status List may give a Relying
Party additional information about up-to-date status of the
Referenced Token.
4. Status List
A Status List is a byte array that contains the statuses of many
Referenced Tokens represented by one or multiple bits. A common
representation of a Status List is composed by the following
algorithm:
1. Each status of a Referenced Token MUST be represented with a bit-
size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for
a Referenced Token are possible, depending on the bit-size. This
limitation is intended to limit bit manipulation necessary to a
single byte for every operation and thus keeping implementations
simpler and less error prone.
2. The overall Status List is encoded as a byte array. Depending on
the bit-size, each byte corresponds to 8/(#bit-size) statuses
(8,4,2, or 1). The status of each Referenced Token is identified
using the index that maps to one or more specific bits within the
byte array. The index starts counting at 0 and ends with "size"
- 1 (being the last valid entry). The bits within an array are
counted from least significant bit "0" to the most significant
bit ("7"). All bits of the byte array at a particular index are
set to a status value.
Looker, et al. Expires 9 August 2024 [Page 6]
Internet-Draft Token Status List February 2024
3. The complete byte array is compressed using the "DEFLATE"
[RFC1951] compression method and stored using the "ZLIB"
[RFC1950] data format. Implementations are RECOMMENDED to use
the highest compression level available.
The following example illustrates a Status List that represents the
statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the
uncompressed byte array:
status[0] = 1
status[1] = 0
status[2] = 0
status[3] = 1
status[4] = 1
status[5] = 1
status[6] = 0
status[7] = 1
status[8] = 1
status[9] = 1
status[10] = 0
status[11] = 0
status[12] = 0
status[13] = 1
status[14] = 0
status[15] = 1
These bits are concatenated:
byte 0 1 2
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+...
values |1|0|1|1|1|0|0|1| |1|0|1|0|0|0|1|1| |0|...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+...
index 7 6 5 4 3 2 1 0 15 ... 10 9 8 23
\_______________/ \_______________/
0xB9 0xA3
4.1. Status List in JSON Format
This section defines the structure for a JSON-encoded Status List:
* status_list: REQUIRED. JSON Object that contains a Status List.
The object contains exactly two 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.
Looker, et al. Expires 9 August 2024 [Page 7]
Internet-Draft Token Status List February 2024
- 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 (as defined in Section 2 of
[RFC7515]) Status List as specified in Section 4.
The following example illustrates the JSON representation of the
Status List:
byte_array = [0xb9, 0xa3]
encoded:
{
"bits": 1,
"lst": "eNrbuRgAAhcBXQ"
}
4.2. Status List in CBOR Format
TBD
5. Status List Token
A Status List Token embeds the Status List into a token that is
cryptographically signed and protects the integrity of the Status
List. This allows for the Status List Token to be hosted by third
parties or be transferred for offline use cases.
This section specifies Status List Tokens in Json Web Token (JWT) and
Cbor Web Token (CWT) format.
5.1. Status List Token in JWT Format
The Status List Token MUST be encoded as a "JSON Web Token (JWT)"
according to [RFC7519].
The following content applies to the JWT Header:
* typ: REQUIRED. The JWT type MUST be statuslist+jwt.
The following content applies to the JWT Claims Set:
* iss: REQUIRED. The iss (issuer) claim MUST specify a unique
string identifier for the entity that issued the Status List
Token. In the absence of an application profile specifying
otherwise, compliant applications MUST compare issuer values using
the Simple String Comparison method defined in Section 6.2.1 of
[RFC3986]. The value MUST be equal to that of the iss claim
contained within the Referenced Token.
Looker, et al. Expires 9 August 2024 [Page 8]
Internet-Draft Token Status List February 2024
* sub: REQUIRED. The sub (subject) claim MUST specify a unique
string identifier for that 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 MAY convey the
time at which it is considered expired by its issuer.
* 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 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.
3. Relying parties MUST reject JWTs that are not valid in all other
respects per "JSON Web Token (JWT)" [RFC7519].
4. Application of additional restrictions and policy are at the
discretion of the verifying party.
The following is a non-normative example for a Status List Token in
JWT format:
Looker, et al. Expires 9 August 2024 [Page 9]
Internet-Draft Token Status List February 2024
{
"alg": "ES256",
"kid": "12",
"typ": "statuslist+jwt"
}
.
{
"exp": 2291720170,
"iat": 1686920170,
"iss": "https://example.com",
"status_list": {
"bits": 1,
"lst": "eNrbuRgAAhcBXQ"
},
"sub": "https://example.com/statuslists/1"
}
5.2. Status List Token in CWT Format
TBD
6. Referenced Token
6.1. Status Claim
By including a "status" claim in a Referenced Token, the issuer is
referencing a mechanism to retrieve status information about this
Referenced Token. The claim contains members used to reference to a
status list 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 JWT Format
The Referenced Token MUST be encoded as a "JSON Web Token (JWT)"
according to [RFC7519].
The following content applies to the JWT Claims Set:
* iss: REQUIRED. The iss (issuer) claim MUST specify a unique
string identifier for the entity that issued the Referenced Token.
In the absence of an application profile specifying otherwise,
compliant applications MUST compare issuer values using the Simple
String Comparison method defined in Section 6.2.1 of [RFC3986].
The value MUST be equal to that of the iss claim contained within
the referenced Status List Token.
Looker, et al. Expires 9 August 2024 [Page 10]
Internet-Draft Token Status List February 2024
* 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. The object contains exactly
two claims:
o idx: REQUIRED. The idx (index) claim MUST specify an
Integer that represents the index to check for status
information in the Status List for the current Referenced
Token. The value of idx MUST be a non-negative number,
containing a value of zero or greater.
o uri: REQUIRED. The uri (URI) claim MUST specify a String
value that identifies the Status List 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"
}
.
{
"iss": "https://example.com",
"status": {
"status_list": {
"idx": 0,
"uri": "https://example.com/statuslists/1"
}
}
}
6.3. Referenced Token in CWT/CBOR Format
TBD
Looker, et al. Expires 9 August 2024 [Page 11]
Internet-Draft Token Status List February 2024
7. Status Types
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.
7.1. Status Types Values
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.
8. Verification and Processing
8.1. Status List Request
To obtain the Status List or Status List Token, the Relying Party
MUST send a HTTP GET request to the Status List Endpoint.
Communication with the Status List Endpoint 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].
Looker, et al. Expires 9 August 2024 [Page 12]
Internet-Draft Token Status List February 2024
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.
8.2. Status List Response
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].
8.3. Caching
If caching is required (e.g., to enable the use of alternative
mechanisms for hosting, like Content Delivery Networks), the control
of the caching mechanism SHOULD be implemented using the standard
HTTP Cache-Control as defined in [RFC9111].
Looker, et al. Expires 9 August 2024 [Page 13]
Internet-Draft Token Status List February 2024
8.4. Validation Rules
TBD
9. Further Examples
9.1. Status List Token with 2-Bit Status Values in JWT format
In this example, the Status List additionally includes the Status
Type "SUSPENDED". As the Status Type value for "SUSPENDED" is 0x02
and does not fit into 1 bit, the "bits" is required to be 2.
This example Status List represents the status of 12 Referenced
Tokens, requiring 24 bits (3 bytes) of status.
status[0] = 1
status[1] = 2
status[2] = 0
status[3] = 3
status[4] = 0
status[5] = 1
status[6] = 0
status[7] = 1
status[8] = 1
status[9] = 2
status[10] = 3
status[11] = 3
These bits are concatenated:
byte 0 1 2
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
status 3 0 2 1 1 0 1 0 3 3 2 1
index 3 2 1 0 7 6 5 4 11 10 9 8
\___________/ \___________/ \___________/
0xC9 0x44 0xF9
Resulting in the byte array and compressed/base64url encoded status
list:
Looker, et al. Expires 9 August 2024 [Page 14]
Internet-Draft Token Status List February 2024
byte_array = [0xc9, 0x44, 0xf9]
encoded:
{
"bits": 2,
"lst": "eNo76fITAAPfAgc"
}
10. Security Considerations
10.1. Correct decoding and parsing of the encoded status list
TODO elaborate on risks of incorrect parsing/decoding leading to
erroneous status data
10.2. Cached and Stale status lists
TODO consumers/Relying Party of the status list should be aware if
they fetch the up-to-date data
10.3. Authorized access to the Status List
TODO elaborate on authorization mechanisms preventing misuse and
profiling as described in privacy section
10.4. History
TODO elaborate on status list only providing the up-to date/latest
status, no historical data, may be provided by the underlying hosting
architecture
11. Privacy Considerations
11.1. Issuer tracking and Herd Privacy
The main privacy consideration for a Status List, especially in the
context of the Issuer-Holder-Verifier model, 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.
Looker, et al. Expires 9 August 2024 [Page 15]
Internet-Draft Token Status List February 2024
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.
11.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.
11.3. Relying Party tracking
Once the Relying Party gets the Referenced Token, this enables him to
request the Status List to validate the status of the Token through
the provided "uri" property 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 constrained by
adding authorization rules to the Status List, see Section 10.3.
11.4. Correlation Risks and Tracking
Colluding Issuers and Relying Parties have the possibility to
identify the usage of credentials of a particular Holder, as the
Referenced Token contains unique, trackable data.
Looker, et al. Expires 9 August 2024 [Page 16]
Internet-Draft Token Status List February 2024
To avoid privacy risks for colluding Relying Parties, it is
recommended that Issuers use batch issuance to issue multiple tokens,
such that Holders can use individual tokens for specific Relying
Parties. In this case, every Referenced Token MUST have a dedicated
Status List entry. Revoking batch issued Referenced Tokens might
reveal this correlation later on.
To avoid information leakage by the values of "uri" and "index",
Issuers are RECOMMENDED to:
* choose non-sequential, pseudo-random or random indices
* use decoy or dead entries to obfuscate the real number of
Referenced Tokens within a Status List
* choose to deploy and utilize multiple Status Lists simultaneously
11.5. Third Party Hosting
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.
12. Implementation Considerations
TBD Declare whether JWT and CWT representations can be used
interchangeably by the same issuer. For instance, declare whether a
status list can reference both JWT and CWT tokens.
13. IANA Considerations
13.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].
13.1.1. Registry Contents
* Claim Name: status
* Claim Description: Reference to a status or validity mechanism
containing up-to-date status information on the JWT.
* Change Controller: IETF
Looker, et al. Expires 9 August 2024 [Page 17]
Internet-Draft Token Status List February 2024
* Specification Document(s): Section 6.1 of this specification
13.2. JWT Status Mechanism Methods Registry
This specification establishes the IANA "Status Mechanism Methods"
registry for JWT "status" member values. The registry records the
status mechanism method member and a reference to the specification
that defines it.
13.2.1. Registration Template
Status Method Value:
The name requested (e.g., "status_list"). The name is case
sensitive. Names may not match other registered names in a case-
insensitive manner unless the Designated Experts state that there
is a compelling reason to allow an exception.
Status Method Description:
Brief description of the status mechanism method.
Change Controller:
For 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.
13.2.2. Initial Registry Contents
* Status Method Value: status_list
* Status Method Description: A status list containing up-to-date
status information on multiple other JWTs encoded as a bitarray.
* Change Controller: IETF
* Specification Document(s): Section 6.2 of this specification
Looker, et al. Expires 9 August 2024 [Page 18]
Internet-Draft Token Status List February 2024
13.3. 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 JSON-based Status List:
* Type name: application
* Subtype name: statuslist+json
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary; A JSON-based Status List is a
JSON Object.
* Security considerations: See (#Security) 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:
- File extension(s): n/a
- Macintosh file type code(s): 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
Looker, et al. Expires 9 August 2024 [Page 19]
Internet-Draft Token Status List February 2024
* 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: binary; A JWT-based Status List is a JWT;
JWT values are encoded as a series of base64url-encoded values
(some of which may be the empty string) separated by period ('.')
characters.
* Security considerations: See (#Security) 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:
- File extension(s): n/a
- Macintosh file type code(s): 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
Looker, et al. Expires 9 August 2024 [Page 20]
Internet-Draft Token Status List February 2024
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: binary; A CBOR-based Status List is a
CBOR Object.
* Security considerations: See (#Security) 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:
- File extension(s): n/a
- Macintosh file type code(s): 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
Looker, et al. Expires 9 August 2024 [Page 21]
Internet-Draft Token Status List February 2024
* Subtype name: statuslist+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary;
* Security considerations: See (#Security) 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:
- File extension(s): n/a
- Macintosh file type code(s): 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. References
14.1. Normative References
[IANA.JWT] "*** BROKEN REFERENCE ***".
Looker, et al. Expires 9 August 2024 [Page 22]
Internet-Draft Token Status List February 2024
[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>.
[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>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>.
[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>.
[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>.
[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>.
Looker, et al. Expires 9 August 2024 [Page 23]
Internet-Draft Token Status List February 2024
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
14.2. Informative References
[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>.
Acknowledgments
We would like to thank Brian Campbell, Filip Skokan, Francesco
Marino, Guiseppe De Marco, Kristina Yasuda, Michael B. Jones, Mike
Prorock, Orie Steele, Timo Glastra and Torsten Lodderstedt
for their valuable contributions, discussions and feedback to this
specification.
Document History
-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
Looker, et al. Expires 9 August 2024 [Page 24]
Internet-Draft Token Status List February 2024
* Change typo in Status List Token sub claim description
* Add access token as an example use-case
-00
* Initial draft after working group adoption
* update acknowledgments
* renamed Verifier to Relying Party
* added IANA consideration
[ draft-ietf-oauth-status-list ]
-01
* Applied editorial improvements suggested by Michael Jones.
-00
* Initial draft
Authors' Addresses
Tobias Looker
MATTR
Email: tobias.looker@mattr.global
Paul Bastian
Email: paul.bastian@posteo.de
Christian Bormann
Email: chris.bormann@gmx.de
Looker, et al. Expires 9 August 2024 [Page 25]