Author: Taisei Igarashi ( @MizukiSonoko / sonoko@mizuki.io
).
This document specifies Terms of Use for chain reaction revocation.
- Introduction
- Details
- References
This section from this issue [1] in w3c/vc-data-model repository
According to spec [2]. There are many mentions about revocation, such as
- An issuer might revoke a verifiable credential. in 5.1 Lifecycle Details
- The holder and verifier trust the issuer to issue true (that is, not false) credentials about the subject, and to revoke them quickly when appropriate. in 5.2 Trust Model
- verifiable data registry has revocation state of vc.
However, my understanding is that there is no mention of chain reaction revocation.
Therefore I propose PreconditionPolicy
to TermOfUse for working chain reaction revocation correctly.
Chain reaction revocation, as defined in this spec, pertains to a process within complex network where the revocation of verifiable credential from a single issuer triggers a cascading effect, leading to subsequent revocations throughout the interconnected network. This concept draws its analogy from a nuclear chain reaction, where the reaction of a single atom leads to a cascading effect impacting numerous other atoms.
For example,
- Issuer A issued
VCa
to holder M, VCa claimsM have graduated the X Univ
. - Issuer B issued
VCb
to holder M, VCb claimsM is employee of Company Y
. and Company Y requires that M have graduated the X Univ. - Issuer C issued
VCc
to holder M, VCc claimsM is employee of Company Z
. and Company Z requires that M have graduated the X Univ and A is a retired employee of Company Y.
In this case, when VCb
or VCa
revoked, I think it would be more correct to revoke VCc
in a chain reaction.
but any Issuer are independent, so only Issuer C
can revoke the VCc
and if Issuer C
is unaware, it is valid until expiration date.
Currently, there is no normalized specification for the type
of TermsOfUse, and each Issuer can define it independently.
However, there are some problem, such as
- Without normalization, it is difficult to verify mechanical verification of chain reactive.
- It is necessary to check the policy of termsOfUse every time.
PreconditionPolicy
,VerifierPolicy
and so on. Therefore, I propose to normalize it by the name ofPreconditionPolicy
in this Specification.
Normalize the policy named PreconditionPolicy
as a Type in termsOfUse. and propose a type section to
https://www.w3.org/TR/vc-data-model/#terms-of-use
"termsOfUse": [{
"type": "PreconditionPolicy",
"id": "http://example.com/policies/credential/4",
"obligation": [{
"assigner": "<did of holder>",
"assignee": "AllVerifiers",
"target": ["<dids of VC, if VC was revoked, this VC is revoked>"],
"action": ["Verify"]
}]
}],
If this PreconditionPolicy
is type
, and included in the termsOfUse
, it is recommended that the Verifier go back and verify the target to check if it is Valid.
If the Verifier finds even one VC that is Expired/Invalid, it is recommended that this VC be treated as Invalid at that point.
In PreconditionPolicy
shema, there is obligation schema. and it includes these properties.
The item must contain the following items.
- assigner: the holder (the assigner).
- assignee: verifiers (the assignee). Basically, "AllVerifiers" is in.
- target: array of ids. Containing the DIDs of the VCs to be verified
- action: actions. Basically, ["Verify"] is in.
[1] Issue How could we deals with chain reaction revocation of VC?
, w3c/vc-data-model#1072
[2] Verifiable Credentials Data Model v1.1, https://www.w3.org/TR/vc-data-model/
https://www.w3.org/TR/vc-extensions/#terms-of-use