precondition_policy_spec.md

Precondition Policy Terms of Use (Draft)

Author: Taisei Igarashi ( @MizukiSonoko / sonoko@mizuki.io ).

Abstract

This document specifies Terms of Use for chain reaction revocation.

Table of Contents

• Introduction
• Details
• References

1. Introduction/Background

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.

1.1 Chain Reaction Revocation

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.

1.2 Example Use Case

For example,

• Issuer A issued VCa to holder M, VCa claims M have graduated the X Univ.
• Issuer B issued VCb to holder M, VCb claims M is employee of Company Y. and Company Y requires that M have graduated the X Univ.
• Issuer C issued VCc to holder M, VCc claims M 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.　

1.3 Necessity

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 of PreconditionPolicy in this Specification.

2. Details

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.

2.1 obligation

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.

3. References

[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/