Skip to content

Commit 199cc82

Browse files
authored
Merge branch 'main' into pb/holdersfetching3
2 parents 5592ba6 + 55b08df commit 199cc82

File tree

1 file changed

+6
-5
lines changed

1 file changed

+6
-5
lines changed

draft-ietf-oauth-status-list.md

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -234,10 +234,10 @@ Status List:
234234
: An object in JSON or CBOR representation containing a bit array that lists the statuses of many Referenced Tokens.
235235

236236
Status List Token:
237-
: A token in JWT or CWT representation that contains a cryptographically secured Status List.
237+
: A token in JWT (as defined in {{RFC7519}}) or CWT (as defined in {{RFC8392}}) representation that contains a cryptographically secured Status List.
238238

239239
Referenced Token:
240-
: A cryptographically secured data structure that contains a reference to a Status List Token. It is RECOMMENDED to use JSON {{RFC8259}} with JOSE as defined in {{RFC7515}} or CBOR {{RFC8949}} with COSE as defined in {{RFC9052}}. The information from the contained Status List gives the Relying Party additional information about the current status of the Referenced Token. Examples for Referenced Tokens are SD-JWT VC and ISO mdoc.
240+
: A cryptographically secured data structure that contains a "status" claim that is referencing a mechanism to retrieve status information about this Referenced Token. This document defines the Status List mechanism in which case the Referenced Token contains a reference to an entry in a Status List Token. It is RECOMMENDED to use JSON {{RFC8259}} with JOSE as defined in {{RFC7515}} or CBOR {{RFC8949}} with COSE as defined in {{RFC9052}}. Examples for Referenced Tokens are SD-JWT VC and ISO mdoc.
241241

242242
base64url:
243243
: Denotes the URL-safe base64 encoding without padding as defined in Section 2 of {{RFC7515}} as "Base64url Encoding".
@@ -865,7 +865,7 @@ The following is a non-normative example for media type `application/json`:
865865

866866
## Extended Key Usage Extension {#eku}
867867

868-
{{RFC5280}} specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used.
868+
{{RFC5280}} specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used. A certificate's issuer explicitly delegates Status List Token signing authority by issuing a X.509 certificate containing the KeyPurposeId defined below in the extended key usage extension.
869869

870870
The following OID is defined for usage in the EKU extension
871871

@@ -1047,13 +1047,13 @@ Ecosystems that want to use other Status Types than "VALID" and "INVALID" should
10471047

10481048
# Implementation Considerations {#implementation}
10491049

1050-
## Referenced Token Lifecycle {#implementation-lifecycle}
1050+
## Token Lifecycle {#implementation-lifecycle}
10511051

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

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

1056-
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.
1056+
Referenced Tokens may also be issued in batches and be presented by Holders in a one-time-use policy to avoid linkability. In this case, every Referenced Token MUST have a dedicated Status List entry and MAY be spread across multiple Status Lists. Revoking batch-issued Referenced Tokens might reveal this correlation later on.
10571057

10581058
## Default Values and Double Allocation
10591059

@@ -1802,6 +1802,7 @@ CBOR encoding:
18021802
-08
18031803

18041804
* Holders may also fetch and verify Status List Tokens
1805+
* Update terminology for referenced token and Status List Token
18051806

18061807
-07
18071808

0 commit comments

Comments
 (0)