Filter by Credential Expiration

In some cases, an Issuer may want to be able to attach an expiration date to a credential in order to limit its validity. To do so an Issuer adds a claim to the Credential that holds the Credential’s expiration date.

The Lissi Wallet filters credential candidates for proof requests based on a pre-defined expiration attribute and makes sure that expired Credentials cannot be used to answer Proof Requests IF the Proof Request requests the Credential’s expiration date.

How it works

A Credential holds a set of one or more claims (Key-Value Pairs) that attest information about its Holder and/or the Credential itself. For example the following Credentials holds three claims, the Given Name, the Surname and an Expiration Date. The following Credential serves as an example and expires at the 15th August of 2090.

CODE

{ 
"cred_info":{
  "referent":"abcdefghi-123456789-abcdefghi-123456789",
  "attrs":{
    "Given Name":"expired",
    "Surname":"expired",
    "Expiration Time":"2090/08/15"},
  "schema_id":"abcdefghijklm123456789:2:SchemaName:1.0",
  "cred_def_id":"123456789abcdefghijklm:3:CL:66217:CredDefName"}
}

Generally, to answer a Proof Request, the Lissi Wallet displays all Credentials where at least a subset of claims within the Credential match the claims requested in the Proof Request. During this mapping process the Lissi Wallet checks if the Proof Request requests a claim called Expiration Date or Expiration Time. ONLY IF such claim is part of the Proof Request the Lissi Wallet makes sure that no expired Credential can be used to answer the Proof Request. To achieve that the Lissi Wallet searches for the claim Expiration Date or Expiration Time in the Credential and parses its value into an ISO 8601 conform DateTime object:

If parsing is successful and DateTime object is not in the past: Credential can be used to answer Proof Request.
If parsing is successful and DateTime object is in the past: Credential can not be used to answer Proof Request.
If parsing fails: Credential can be used to answer Proof Request and the Verifier is responsible to enforce the expiration of the Credential.

To accommodate for different spellings of the claims Expiration Date or Expiration Time are transformed to their lowercase representation and all spaces are removed during that process. Therefore the claim's spelling in the Proof Request and Credential doesn't matter as long as they equal expirationdate or expirationtime after their transformation. Following examples illustrate the behavior:

Expiration Time → expirationtime
ExpirationDate → expirationdate
expIr ation DatE → expirationdate
expIr ation_Time → expiration_time
exp time → exptime

Implications for Issuer and Verifier

In conclusion the Issuer and Verifier must follow the following rules so the Lissi Wallet is able to enforce the expiration of Credentials:

Issuer

The Issued Credential MUST have a claim Expiration Date or Expiration Time in an ISO 8601 conform format.

Verifier

Verifier MUST request the claim Expiration Date or Expiration Time within the Proof Request. Otherwise the Lissi Wallet does not validate if the Credential is expired.
The Verifier is still responsible to check the Credentials validity and MUST make sure that it is not expired, since the Lissi Wallet can only enforces it on the client side.

Possible ISO8601 conform DateTime formats

The following ISO 8601 conform DateTime formats are tested even though others may work as well.

Basic Format with Slashes: e.g. 2023/08/15
Extended Format (with hyphens): e.g. 2023-08-15
Extended Format (with hyphens and time): e.g. 2023-08-15T12:30:00
Extended Format (with hyphens, time, and timezone): e.g. 2023-08-15T12:30:00+02:00
Date with Time and Decimal Seconds: e.g. 2023-08-15T12:30:00.5
Date with Time and Milliseconds: e.g. 2023-08-15T12:30:00.123
Date with Time, Milliseconds, and Timezone: e.g. 2023-08-15T12:30:00.123+02:00