Revised vLEI design for delegation

[SmithSamuelM]

Revised vLEI Design for Revocable Delegation of Authority to Issue vLEIs

The draft design of the GLEIF verifiable credentials did not provide a convenient way to revoke a vLEIs issuer's authorization to issue vLEIs without also revoking the vLEI issuer's vLEI. With this revocation the vLEI issuer no longer has verifiable authority to revoke vLEIs it issued. Or did it? This also left as ambiguous the status of all the vLEIs issued by that issuer. Should those be automatically revoked or do they become un-revocable? Likewise a vLEI issuer's status as a legal entity may still remain but not its status as a vLEI issuer. Revoking its vLEI credential effectively revokes both its status as a legal entity and as a vLEI issuer when what we really want is to revoke its vLEI issuer status but not necessarily also revoke its legal entity status. As a result another VC is deemed necessary.

vLEI Issuer Authorization Credential

A vLEI Issuer Credential authorizes a vLEI issuer to issue, revoke, and otherwise manage vLEIs in accordance with GLEIF policies and procedures for vLEI issuers and as delimited in the GLEIF eco-system governance framework. When a vLEI issuer falls out of compliance with those policies, GLEIF needs to be able to revoke that issuer's authorization to issue or otherwise manage vLEIs. We propose a new credential called the vLEIIssuerCredential that conveys this authorization. This enables GLEIF to revoke an issuer's issuance authority separately from revoking that issuer's vLEI.

An example vLEIIssuerCredential is as follows:

{
  "@context": 
  [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "id": "did:keri:Eewfge7gf78sgfivsf/vLEIGLEIFCredential", // DID of the verifiable credential itself
  "type": 
  [
    "VerifiableCredential", 
    "vLEIIssuerCredential"
  ], // type of the verifiable credential
  "issuer": "did:keri:Eewfge7gf78sgfivsf/DelegatedGLEIFRootID", // issuer of the verifiable credential
  "issuanceDate": "2021-02-10T17:50:24Z", // date of issuance
  "credentialSubject": 
  {
    "id": "did:keri:Ejnfkjsngsdg7his7dg/LEIIssuerRootID", // DID of the issuee / holder
    "graceMax": 90,  // maximum grace period (days) that vLEI issuer may extend to its issuees to renew post revocation of this credential
     "graceMin": 30  // minimum grace period (days) that vLEI issuer must extend to its issuees to renew post revocation of this credential
  },
  "proof": 
  {
    "type": 
    [
      "Ed25519Signature2018"
    ],  // signature type (Sam to confirm year, i.e. 2018 or different)
    "created": "2021-02-18T21:19:10Z", // date of creation of signature (Sam to provide anchor to KEL part)
    "proofPurpose": "assertionMethod", // purpose of this proof
    "verificationMethod": "https://example.edu/issuers/keys/1", // identifier of the public key that can verify the signature
    "jws": "7igixi7hgfidgh8fidhig7hfdighfdhgihdg" // signature
  }
}

Addressing Cascading Revocation

The problem with revoking an issuer's ability to mange credentials is how to deal with the cascade to vLEI credentials issued by the issuer. The default policy is that a vLEI credential once issued to remains in force until explicitly revoked. But only the issuer may verifiably revoke a credential it issued. Thus should the an issuer fall out of compliance it may longer have the capability of revoking vLEI credentials it issued. Thereby creating zombie vLEI credentials. A vLEI credential likewise may be revoked if the associated legal entity falls out of compliance. Thus a zombie credential would defeat the ability to revoke vLEI credentials to non-compliant legal entities. One important detail is relevant. A legal entity may have multiple vLEI credentials from multiple issuers at any time. The credentials all certify the same vLEI (LEI) belongs to the same provable entity DID. Once issued an LEI is eternal for a given legal entity. The LEI is forever reserved for that entity regardless of the entity's compliance status for that LEI or any vLEIs issued against that LEI.

There are several ways to solve this problem.

• Automatically effectively revoke all vLEIs of non-compliant vLEI issuer: In this case when a vLEI issuer's authorization credential is revoked, all of its issued vLEIs are also automatically effectively revoked. A verifier will not be able to verify a vLEI because the issuer of that vLEI is not longer authorized. This has several disadvantages. It creates a race condition or a time lapse where through not fault of its own a legal entity will not have a valid vLEI until it can find a different but authorized issuer.

• Fixed expiration date with mandatory renewal: With a fixed expiration date on vLEIs all vLEIs will eventually expire regardless of the compliance status of the vLEI issuer. The legal entity renews its vLEI by getting a new vLEI issued by any active authorized (compliant) vLEI issuer. The entity may renew before the expiration date to ensure no lapse in vLEI status. This has the disadvantage of requiring a large volume of vLEI issuances on a regular basis. A vLEI is meant to be a lifetime authorized credential subject to the legal entity remaining in compliance. It is expected that the vast majority of legal entities will remain in compliance at any point in time. Thus a forced time based reissuance would create a lot of extra work.

• Grace period post expiration: In this approach each vLEI has a grace period. The grace period starts if and only if the vLEI issuer's authorization credential has been revoked. It starts on the date of that revocation. The legal entity has until the expiration of the grace period to renew their vLEI from an authorized (compliant) vLEI issuer. This approach as the advantage that renewal never need happen unless a vLEI issuer's authorization credential has been revoked. Given that the vast majority of vLEI issuers are expected to maintain compliance indefinitely then vLEI renewals will be rare. The grace period also avoids the race condition or lapse condition where a vLEI is revoked and the legal entity does not have a valid vLEI. The grace period also limits the time window during which a non-compliant legal entity may hold a valid vLEI. The max and min limits to this time window may be set in the Issuer's authorization credential and then the exact time window for a given vLEI is set within that vLEI. The example issuer authorization credential above provides the max and min grace period. The example vLEI below provides the exact grace period within that allowed max and min limits.

{
  "@context": 
  [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "id": "did:keri:Esd8ghskgih84ihgs/vLEILegalEntityCredential", // DID of the verifiable credential itself
  "type": 
  [
    "VerifiableCredential", 
    "vLEILegalEntityCredential"
  ], // type of the verifiable credential
  "issuer": "did:keri:Ejnfkjsngsdg7his7dg/LEIIssuerRootID", // issuer of the verifiable credential
  "issuanceDate": "2021-02-10T17:50:24Z", // date of issuance
  "issuerAuthorization": "did:keri:Eewfge7gf78sgfivsf/vLEIGLEIFCredential", // DID of the issuer's authorization credential
  "credentialSubject": 
  {
    "id": "did:keri:Ejksbdfugdsidsigsdg/LegalEntityRootID", // DID of the issuee / holder
    "lei": "254900OPPU84GM83MG36", // LEI
    "grace": 60  // grace period in days for renewal of vLEI after issuer's authorization credential is revoked
  },
  "proof": 
  {
    "type": 
    [
      "Ed25519Signature2018"
    ], // signature type (Sam to confirm year, i.e. 2018 or different)
    "created": "2021-02-18T21:19:10Z", // date of creation of signature (Sam to provide anchor to KEL part)
    "proofPurpose": "assertionMethod", // purpose of this proof
    "verificationMethod": "https://example.edu/issuers/keys/1", // identifier of the public key that can verify the signature
    "jws": "ksdgfi7sdfbidsifiafbkadbkfbdakbff" // signature
  }
}

In addition to the grace period field in the credentialSubject, the vLEI credential also has been modified to include a reference to the issuerAuthorization credential in the issuerAuthorization field. This allows a validator to lookup the authorization credential.

Renewal

The term renewal used herein when referring to a verifiable credential means revoke and replace. Verifiable credentials are verifiable in the sense that they have attached a cryptographic non-repudiable digital signature. A digital signature will not verify if even one bit in the serialized data in the VC has changed. Thus there is no cryptographically verifiable (secure) way to mutate or change a verifiable credential. The only way to renew a credential is to revoke the old one and then replace it with a new one with the new field values and new signatures. In the case where an issuer has its authorization to issue revoked, the issuer field in the original credential may not be changed to a new issuer without creating a new credential and that is signed by the new issuer. Cryptographic security does not allow in-place mutation of signed data. Likewise a reference or pointer in a VC to some other data that is mutable is inherently insecure. The signature on the VC itself does not guarantee either the integrity nor the authenticity of that external mutable data. Any system that depends on such mutability is subject to numerous exploits that do not require compromising private keys. VC systems that reference external mutable data are inherently insecure relative to VC systems that only reference extennal immutable data. A cryptographic digest is one way to securely reference external immutable data. Any verifier may compute the digest on the external data to verify that it has not changed since the reference digest was created. Moreover a signature on a reference digest makes a verifiable non-repudiable commitment to the contents of that external data. The only attack is to compromise the keys used to create that signature or the code used to verify that signature. This limits the attack surface to a manageable size and makes key management infrastructure which includes signing and signature verification infrastructure the focus of secure system design.

[SmithSamuelM]

Grace Period

GRACE_PERIOD

gracePeriod 90 days

Qualified vLEI Issuer Credential Type

QualifiedvLEIssuerCredential

Credential Types with Fields

GLEIvLEICredential

• LEI

QualifiedvLEIIssuervLEICredential

• LEI
• gracePeriod (90 days)

LegalEntityvLEICredential

• LEI
• qualifiedvLEIIssuervLEICredential

LegalEntityOfficialOrganizationalRolevLEICredential

• LEI
• personLegalName
• officialRole
• qualifiedvLEIIssuervLEICredential

LegalEntityEngagementContextRolevLEICredential

• LEI
  • personLegalName
• engagementContextRole
• qualifiedvLEIIssuervLEICredential

Fields

LEI gracePeriod personLegalName officialRole engagementContextRole qualifiedvLEIIssuervLEICredential

[SmithSamuelM]

Proposed specification strategy is to specify both flavors of credential, that are, common VC flavor and the new ACDC flavor.

In the common VC flavor the qualifiedvLEIIssuervLEICredential field is in the credentialSubject property block. In the ACDC flavor the qualifiedvLEIIssuervLEICredential is in the source block. Both flavors with use SAID for schema and VC identifiers. Two variants of each VC schema will be specified one where all Schema are referenced by SAID only and two where the full schema is embedded in the VC (but still self-referenced by SAID).

[pfeairheller]

Good, you anticipated my first question already. I was wondering how the chain would work with it specified as a field here but in ACDC would be in source, presumably with the same name as a label.

[SmithSamuelM]

ACDC flavor has the following blocks: s source block , d data block, x schema block and the r rule block. The r block is not used for vLEIs. The common flavor has the credentailSubject etc blocks. The plan is to define schema and example VCs for both flavors, not because we prefer to implement both flavors but because it will help users map between the two flavors and there is the anticipation that some users may only want to support the common flavor and so we might then have to support it in implementation in addition to the ACDC flavor.

[SmithSamuelM]

Implemented Grace Period

[SmithSamuelM]

See details of credential schema for grace period and ecosystem goveranance framework docs for usage.