Feature Request
The IssuerService must host a revocation list credential, which verifiers can download when they determine a credential's revocation status.
There should be a CredentialRevocationService, which allows to revoke, suspend, resume and query the status of a certain credential.
Metadata about issued credentials is stored anyways (cf. Credentials Admin API, #536), and that data model should then also contain the revocation status.
Upon change, the metadata in the DB gets updated, and the revocation list credential gets regenerated and signed. The revocation credential then is resolved through a (static, unauthenticated) web endpoint.
Requirements
Transactional updates:
the revocation list credential must always reflect a consistent state
data model:
credential metadata is stored in the DB using the VerifiableCredentialResource. The bit string must never be stored in an unsigned state, but be secured with a proof. Only JWT proofs will be supported
Credential resolution
- the static web endpoint must be publicly visible and must not require authn/authz
Content types:
by default, the revocation credential is returned as signed JWT VC, the response Content-Type header must reflect that (applications/vc+jwt). Upon client request (Accept=application/json header), the endpoint may respond with an unsigned JSON body (application/json). If the Accept header is not understood, the endpoint responds with 415 unsupported media type.
Variants
- implementations for StatusList20201 and BitStringStatusList must be provided as extensions
- BitStringStatusList: only two states and the minimum required bistring length are supported initially
Why Is the Feature Desired?
to allow verifiers to determine the revocation state of credentials issued by this issuer
Who will sponsor this feature?
Please @-mention the committer that will sponsor your feature.
Solution Proposal
If possible, provide a (brief!) solution proposal.
Feature Request
The IssuerService must host a revocation list credential, which verifiers can download when they determine a credential's revocation status.
There should be a
CredentialRevocationService, which allows to revoke, suspend, resume and query the status of a certain credential.Metadata about issued credentials is stored anyways (cf. Credentials Admin API, #536), and that data model should then also contain the revocation status.
Upon change, the metadata in the DB gets updated, and the revocation list credential gets regenerated and signed. The revocation credential then is resolved through a (static, unauthenticated) web endpoint.
Requirements
Transactional updates:
the revocation list credential must always reflect a consistent state
data model:
credential metadata is stored in the DB using the
VerifiableCredentialResource. The bit string must never be stored in an unsigned state, but be secured with a proof. Only JWT proofs will be supportedCredential resolution
Content types:
by default, the revocation credential is returned as signed JWT VC, the response
Content-Typeheader must reflect that (applications/vc+jwt). Upon client request (Accept=application/jsonheader), the endpoint may respond with an unsigned JSON body (application/json). If theAcceptheader is not understood, the endpoint responds with 415 unsupported media type.Variants
Why Is the Feature Desired?
to allow verifiers to determine the revocation state of credentials issued by this issuer
Who will sponsor this feature?
Please @-mention the committer that will sponsor your feature.
Solution Proposal
If possible, provide a (brief!) solution proposal.