From 7cd51970713f20c2e8abe1f7421801f1af5030a2 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Sep 2024 18:52:36 +0200 Subject: [PATCH 1/5] add implementation consideration for Default Values and Double Allocation --- draft-ietf-oauth-status-list.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 66c92be..72a9872 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -632,10 +632,16 @@ TODO evaluate definition of Status List Provider? 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 increase security or to mitigate linkability and prevent tracking by Relying Parties. In this case, every Referenced Token MUST have a fresh Status List entry. +Referenced Tokens may be regularly re-issued to increase security or to mitigate linkability and limit tracking by the Relying Parties. In this case, every re-issued Referenced Token MUST have a fresh Status List entry. 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. +## Default Values and Double Allocation + +The implementation is 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. + +The implementation is RECOMMENDED to prevent double allocation, i.e. re-using the same `uri` and `index` for mulitple Referenced Tokens. The Issuer MUST prevent any unintended double allocation by using the Status List. + # IANA Considerations ## JSON Web Token Claims Registration @@ -875,6 +881,7 @@ for their valuable contributions, discussions and feedback to this specification -04 +* add implementation consideration for Default Values and Double Allocation * add CORS considerations to the http endpoint * fix reference of Status List in CBOR format * added status_list CWT claim key assigned From 9fe284ff7dbfbba543be3d39385c3b753beb913c Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 13 Sep 2024 18:53:41 +0200 Subject: [PATCH 2/5] more considerations regarding size --- draft-ietf-oauth-status-list.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 72a9872..df91d69 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -642,6 +642,12 @@ The implementation is RECOMMENDED to initialize the Status List byte array with The implementation is RECOMMENDED to prevent double allocation, i.e. re-using the same `uri` and `index` for mulitple Referenced Tokens. The Issuer MUST prevent any unintended double allocation by using the Status List. +## Status List Size + +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 fills up the byte boundary, i.e. `size` % `bits` = 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. + # IANA Considerations ## JSON Web Token Claims Registration @@ -881,7 +887,7 @@ for their valuable contributions, discussions and feedback to this specification -04 -* add implementation consideration for Default Values and Double Allocation +* add implementation consideration for Default Values, Double Allocation and Status List Size * add CORS considerations to the http endpoint * fix reference of Status List in CBOR format * added status_list CWT claim key assigned From 467ae1b4d957d9613a4f86bfae11da9834211ec9 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 18 Sep 2024 11:50:26 +0200 Subject: [PATCH 3/5] Update draft-ietf-oauth-status-list.md Co-authored-by: Tobias Looker --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index df91d69..63d9472 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -632,7 +632,7 @@ TODO evaluate definition of Status List Provider? 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 increase security or to mitigate linkability and limit tracking by the Relying Parties. In this case, every re-issued Referenced Token MUST have a fresh Status List entry. +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. From 1ccb2ab34883211e2126cc57417224b4ee90434c Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 19 Sep 2024 18:01:53 +0200 Subject: [PATCH 4/5] Apply suggestions from code review Co-authored-by: Tobias Looker --- draft-ietf-oauth-status-list.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 63d9472..b2ed804 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -638,9 +638,9 @@ Referenced Tokens may also be issued in batches, such that Holders can use indiv ## Default Values and Double Allocation -The implementation is 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 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. -The implementation is RECOMMENDED to prevent double allocation, i.e. re-using the same `uri` and `index` for mulitple Referenced Tokens. The Issuer MUST prevent any unintended double allocation by using the Status List. +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. ## Status List Size From 5408499959ed5e9fae9e64348fe1d685eae08b45 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 20 Sep 2024 21:52:09 +0200 Subject: [PATCH 5/5] Update draft-ietf-oauth-status-list.md Co-authored-by: Tobias Looker --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index b2ed804..a75df57 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -644,7 +644,7 @@ Implementations producing Status Lists are RECOMMENDED to prevent double allocat ## Status List Size -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 fills up the byte boundary, i.e. `size` % `bits` = 0. +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.