Skip to content

Commit ee0e8e1

Browse files
committed
add reference
1 parent c7f8f0a commit ee0e8e1

File tree

1 file changed

+4
-2
lines changed

1 file changed

+4
-2
lines changed

draft-ietf-oauth-status-list.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -664,6 +664,8 @@ This document creates a registry in [](#iana-status-types) that includes the mos
664664

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

667+
See [](#privacy-status-types) for privacy considerations on status types.
668+
667669
# Verification and Processing
668670

669671
## Status List Request {#status-list-request}
@@ -973,13 +975,13 @@ By default, this specification only supports providing Status List information f
973975

974976
There are strong privacy concerns that have to be carefully taken into consideration when providing a mechanism that allows historic requests for status information - see [](#privacy-relying-party) for more details. Support for this functionality is optional and Implementers are RECOMMENDED to not support historic requests unless there are strong reasons to do so and after carefully considering the privacy implications.
975977

976-
## Other Status Types
978+
## Status Types {#privacy-status-types}
977979

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

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

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

984986
# Implementation Considerations {#implementation}
985987

0 commit comments

Comments
 (0)