Token Lifecycle

[Denisthemalice]

The content of section 13.1 (Token Lifecycle) does not contain sufficient guidance.

The following guidance is rather vague:

The lifetime of a Status List Token depends on the lifetime of its eferenced Tokens.

Since the exp (expiration time) claim in a Status List Token is OPTIONAL, it is hard to understand how this sentence can be used.

The three paragraphs do not provide sufficient information

Proposed text replacement:

The Issuer and the Status issuer SHALL initially agree on the following set of parameters:

• the number of bits that indicates the status of each Referenced Token,
• the number of entries in a Status List,
• the number of Status Lists initially available,
• one or more absolute uris where the Status List Tokens will be made available by the Status issuer,
• a relative uri associated with each Status List (that can also be used to reference a given Status List).

The Issuer CAN communicate to the Status issuer the "time to live" which is the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved ('ttl' claim). If the "time to live" is communicated, then the Status issuer SHALL include it into each Status List Token.

For every Status List, the Issuer SHALL communicate to the Status issuer the date when each Status List will cease to be updated by the Issuer.
For every Status List, the Issuer CAN communicate to the Status issuer the time at which the Status List Token will be considered expired. If the expiration time is communicated, then the Status issuer SHALL include the 'exp' claim into the Status List Token.

At any time, the Status issuer and the Issuer may agree to use a new set of parameters. For every Status List already agreed, the agreed parameters remain applicable until the date when the Status List will cease to be updated by the Issuer is reached.

The Status issuer SHOULD issue and distribute Status List Tokens before the first Referenced Token is issued by the Issuer.

The status of Referenced Tokens with close expiration times should be grouped together into Status Lists so the corresponding Status List Tokens can be no longer issued and distributed once all the Referenced Tokens referenced in it have expired.

The text continues with :

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.

The concept of Referenced Tokens that would be regularly re-issued means a same content with a different validity period.

The following sentence looks odd:

Referenced Tokens may be regularly re-issued to mitigate linkability of presentations to Relying Parties.

Since the content of the referenced Token is nearly the same, linkability can easily be achieved and a re-issuance of Referenced Tokens will be unable "to mitigate linkability of presentations to Relying Parties".

These two sentences should be removed.

The text ends-up with :

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.

The right wording is not "batch issuance of Referenced Tokens" but "one-time-use Referenced Tokens"
The second sentence has nothing to do with a consequence of the previous sentence as it applies to every Referenced Token, whether or not it is a one-time-use Referenced Token.

These three sentences should be removed.

Proposed text replacement:

One-time-use Referenced Tokens may also be issued in batches, such that Holders can use a different Referenced Token for every transaction. In this case, the status of every one-time-use Referenced Token SHOULD be handled in a different Status list so that a global revocation of these one-time-use Referenced Tokens cannot be used to reveal a correlation later on.

[paulbastian]

Editors Call:

• agree to add implementation guidance what needs to be negotiated between Issuer and Status Issuer
• don't agree with the other recommendations in this issue, i.e. no privacy gains