diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS deleted file mode 100644 index a526ee3..0000000 --- a/.github/CODEOWNERS +++ /dev/null @@ -1,3 +0,0 @@ -# Automatically generated CODEOWNERS -# Regenerate with `make update-codeowners` -draft-ietf-oauth-status-list.md tobias.looker@mattr.global paul.bastian@posteo.de chris.bormann@gmx.de diff --git a/.gitignore b/.gitignore index 8a96a98..c598200 100644 --- a/.gitignore +++ b/.gitignore @@ -1,28 +1,24 @@ +*~ +/*-[0-9][0-9].xml +archive.json +draft-ietf-oauth-status-list.xml +Gemfile.lock +/.gems/ *.html +/.idea/ +/lib +/.*.mk +/node_modules/ +package-lock.json *.pdf *.redxml +/.refcache +report.xml *.swp +.tags *.txt *.upload -*~ -.idea/ -.includes.mk -.tags -/*-[0-9][0-9].xml -/.*.mk -/.gems/ -/.refcache -/.targets.mk /.venv/ -/.vscode/ -/lib -/node_modules/ /versioned/ -Gemfile.lock -__pycache__ -archive.json -draft-ietf-oauth-status-list.xml -examples/ -package-lock.json -report.xml +/.vscode/ !requirements.txt diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index d60f3ba..bc11b4b 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -176,13 +176,13 @@ The following diagram depicts the relationship between the involved roles (Relyi ~~~ -Status Lists may be composed to express 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. +Status Lists can be used to express a variety 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. Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. ## Example Use Cases -An example of the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of {{RFC6749}}. Token Introspection {{RFC7662}} defines a way to determine the status of an issued access token, but it requires the party trying to validate the state of access tokens to directly contact the Issuer of the access tokens for each token validation. In contrast, the mechanism defined in this specification allows a party to fetch the status for many tokens, reducing interactions with the Issuer significantly for better scalability and providing better privacy as the Issuer does not learn which specific access token is being verified (herd anonymity). +An example of the usage of a Status List is to manage the statuses of issued access tokens as defined in section 1.4 of {{RFC6749}}. Token Introspection {{RFC7662}} provides a method to determine the status of an issued access token, but it necessitates the party attempting to validate the state of access tokens to directly contact the Issuer of each token for validation. In contrast, the mechanism defined in this specification allows a party to retrieve the statuses for many tokens, reducing interactions with the Issuer substantially. This not only improves scalability but also enhances privacy by preventing the Issuer from gaining knowledge of access tokens being verified (herd anonymity). 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}}. @@ -250,7 +250,7 @@ base64url: # Status List {#status-list} -A Status List is a data structure that contains the statuses of many Referenced Tokens represented by one or multiple bits. The [first section](#status-list-byte-array) describes how to construct a compressed byte array that is the base component for the Status List data structure. The second and third section describe how to encode such a Status List in JSON and CBOR representation. +A Status List is a data structure that contains the statuses of many Referenced Tokens represented by one or multiple bits. The [first section](#status-list-byte-array) describes how to construct a compressed byte array that is the base component for the Status List data structure. The second and third sections describe how to encode such a Status List in JSON and CBOR representations. ## Compressed Byte Array {#status-list-byte-array} @@ -783,6 +783,8 @@ In the successful response, the Status Provider MUST use the following content-t In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of [](#status-list-token-jwt). In the case of "application/statuslist+cwt", the response MUST be of type CWT and follow the rules of [](#status-list-token-cwt). +The body of such an HTTP response contains the raw Status List Token, that means the binary encoding as defined in section 9.2.1 of {{RFC8392}} for a Status List Token in CWT format and the JWS Compact Serialization form for a Status List Token in JWT format. Note that while the examples for Status List Tokens in CWT format in this document are provided in hex encoding, this is done purely for readability and does not mean that hex encoding is expected for HTTP messages. + The HTTP response SHOULD use gzip Content-Encoding as defined in {{RFC9110}}. If caching-related HTTP headers are present in the HTTP response, Relying Parties MUST prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior. @@ -869,9 +871,10 @@ An Issuer MAY support any of these mechanisms: ## Issuer Metadata -The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID or within Issuer certificates or trust lists (such as VICAL as defined in Annex C of {{ISO.mdoc}}). If the Issuer is an OAuth Authorization Server according to {{RFC6749}}, it is RECOMMENDED to use `status_list_aggregation_endpoint` for its metadata defined by {{RFC8414}}. The Issuer MAY limit the Status List Tokens listed by a Status List Aggregation to a particular type of Referenced Token. +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 Connect, or within Issuer certificates or trust lists (such as VICAL as defined in Annex C of {{ISO.mdoc}}). If the Issuer is an OAuth Authorization Server according to {{RFC6749}}, it is RECOMMENDED to use `status_list_aggregation_endpoint` for its metadata defined by {{RFC8414}}. The Issuer MAY limit the Status List Tokens listed by a Status List Aggregation to a particular type of Referenced Token. + +The concrete implementation details depend on the specific ecosystem and are out of scope of this specification. -The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification. ## Status List Parameter @@ -956,7 +959,7 @@ Alternatively, the Status Issuer may use the same web-based key resolution that │ Status Provider │ └─────────────────┘ ~~~ -If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by an Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize [extended key usage](#eku). +If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by a Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize [extended key usage](#eku). ~~~ ascii-art ┌───────────────────────┐ @@ -993,9 +996,14 @@ This behaviour may be mitigated by: - private relay protocols or other mechanisms hiding the original sender like {{RFC9458}}. - using trusted Third Party Hosting, see [](#third-party-hosting). -## Malicious Issuers +## Issuer Tracking of Reference Tokens + +An Issuer could maliciously or accidentally bypass the privacy benefits of the herd privacy by either: -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, the Issuer 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. +- Generating a unique Status List for every Referenced Token. By these means, the Issuer 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. +- Encoding a unique URI in each Reference Token which points to the underlying Status List. This may involve using URI components such as query parameters, unique path segments, or fragments to make the URI unique. + +This malicious behavior can be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes with the volume of Reference Tokens being verified. ## Observability of Relying Parties {#privacy-relying-party} @@ -1116,7 +1124,7 @@ When fetching a Status List Token, Relying Parties must carefully evaluate how l - After initial fetching, the Relying Party checks for updates at time of `iat` + `ttl`. This method ensures the most up-to-date information for critical use cases. The Relying Party should account a minimal offset due to the signing and distribution process of the Status Issuer. - If no `ttl` is given, then Relying Party SHOULD check for updates latest after time of `exp`. -Ultimately, its the Relying Parties decision how often to check for updates, ecosystems may define there own guidelines and policies for updating the Status List information. +Ultimately, it's the Relying Parties decision how often to check for updates, ecosystems may define their own guidelines and policies for updating the Status List information. The following diagram illustrates the relationship between these claims and how they are designed to influence caching: @@ -1463,6 +1471,7 @@ IANA is also requested to register the following OID "1.3.6.1.5.5.7.3.TBD" in th {:numbered="false"} We would like to thank +Andrii Deinega, Brian Campbell, Dan Moore, Denis Pinkas, @@ -1899,6 +1908,11 @@ CBOR encoding: # Document History {:numbered="false"} +-13 + +* add a note that cwt is encoded in raw/binary. +* added further privacy consideration around issuer tracking using unique URIs + -12 * Allow for extended key usage OID to be used for other status mechanisms