Skip to main content
Version: 0.6

Revocation Options


The IOTA DIDComm Specification is in the RFC phase and may undergo changes. Suggestions are welcome at GitHub #464.

  • Version: 0.1
  • Status: IN-PROGRESS
  • Last Updated: 2021-10-29


Allows discovery of available RevocationInfo types for use with the revocation protocol.



  • Trusted-Party: requests supported methods of revocation.
  • Revoker: offers supported methods of revocation.



For guidance on diagrams see the corresponding section in the overview.


1. revocation-options-request

  • Type: iota/revocation-options/0.1/revocation-options-request
  • Role: trusted-party

Empty message requesting all available RevocationInfo types.



2. revocation-options

  • Type: iota/revocation-options/0.1/revocation-options
  • Role: revoker

Response including all available RevocationInfo types supported by the revoker.


"revocationInfoTypes": [string], // REQUIRED
revocationInfoTypesList of supported RevocationInfo types.1

1 The actual list of supported types may be vague or exact depending on how much the revoker trusts the requester. The supported types may also differ per requester.


  1. Response including multiple RevocationInfo types:
"revocationInfoTypes": ["KeyRevocation2021", "CredentialRevocation2021", "CredentialStatusRevocation2021"]
  1. Response including a single RevocationInfo type:
"revocationInfoTypes": ["CredentialRevocation2021"]

Problem Reports

The following problem-report codes may be raised in the course of this protocol and are expected to be recognised and handled in addition to any general problem-reports. Implementers may also introduce their own application-specific problem-reports.

For guidance on problem-reports and a list of general codes see problem reports.

e.p.msg.iota.revocation-options.reject-requestrevocation-optionsThe revoker rejects a request for any reason.


This section is non-normative.

  • Privacy: similar to discover features, this protocol could be used to fingerprint a party partially or reveal its capabilities. If privacy is a concern, implementors should take care to accept requests only from parties authorized to perform revocation or return a subset/superset of its actual supported options.

Unresolved Questions

  • Should revocation-options include the credential status sub-types for CredentialStatusRevocation2021?