Revocation List Management Decision

[oriolcanades]

Revocation List Management Decision

Status

Proposed

Context

Currently, we do not have any revocation list that we can implement.
The TIR Service from Fiware only allows registering Issuers and Participants equally (in the same database without distinctions). Additionally, manual manipulation of the database is forbidden for any development team involved in the project. (@wistefan)
Moreover, the TIR Service from Digitel is expected to be available after December, meaning we cannot rely on it to manage revocations in the short term. (@alejandro-nieto-git)

Given that we have a GitHub repository used as our TrustFramework, this opens up the possibility of internally managing revocations.

Decision

A Revocation List will be generated for each environment, which the Verifier will query when performing validation.

This Revocation List can only be updated or altered via Pull Requests (PR) and must be approved by one of the DOME operators.

Once one of the TIR Services and the TIR Management Process is defined by DOME, this Revocation List must be migrated accordingly.

Consequences

• The Verifier will have a method to query and validate revocations.
• Control over updates to the list will be centralized with the DOME operator team, ensuring a secure and supervised process.
• We will not be dependent on external solutions like the TIR from Fiware or Digitel to manage revocations in the short term.

[wistefan]

2 Questions:

• is this talking about a Revocation List for Issuers or VerifiableCredentials? If its for Issuers, why is an additional Revocation List required, instead of plain removal from the Issuers List?
• Was there an analyzes of the expected effort to just extend an existing TIR solution, in comparison to the described approach? From reading the requirements here, I would not expect more that 3-5days of work for extending the FIWARE implementation(maybe even less). When looking at the existing Verifier-PR I would be suprised if the github-approach is much faster.

[oriolcanades]

The Revocation List only includes the Verifiable Credential ID that has been revoked, and does not contain information about the Issuer or Participant.

As for the second question, I'm unable to provide a definitive answer. For the time being, I have privately opted to use a JSON list of VC IDs because it is currently easier for the Verifier Development Team to maintain. In the future, if the TIR Verifier or TIR Digital implements the relevant API, we can explore how best to integrate its security features and API consumption.