Skip to content

Index

Org Vet Credentials

Purpose

This credential asserts with an explicit level of assurance the existence and attributes of an organization. It is issued to a cryptographic identifier controlled by the org, allowing the org to authenticate itself on the basis of the credential. (The LE vLEI is essentially an org vet credential at LoA 3, but its schema varies slightly to express some GLEIF governance requirements.)

suggested org vet visual
Suggested visual: svg | 256 px | 128 px | 64 px | 32 px

Levels of assurance

Levels of assurance (LoAs) are well known and often referenced for individual identity; they are less adopted in organizational identity. In the United States, the FBCA defines basic, medium, and high assurance for certificates issued to federal agencies, but these LoAs are not typically referenced in other contexts. In the EU, eIDAS (EU regulation 910/2014, article 28) defines "nonqualified" and "qualified/QSeal" assurance for certificate issuance — but its rollout is young, and its application for non-certificate-based technologies is unclear.

Org vet credentials convey a level of assurance with a positive number, where larger numbers map to higher levels of assurance (1 < 2 < 3). Normally, these numbers are expected to be integers, but nuances within a given integer can be modeled by using a floating point value instead (2.1 < 2.2). This allows verifiers to decide what level of assurance will satisfy them, and accept any credential having an LoA >= their threshhold. The meaning of the integer values are defined as follows:

LoA intended meaning verification procedures mappings
1 aka "bronze" basic proof of control + authorization of requester; no claim about legalities, tools, governance, tools, or competence
  1. Prove that a non-cryptographic identifier (e.g., an LEI) references an org that exists and is not defunct.
  2. Prove org owns domain.
  3. Prove requester is human and has email in domain.
  4. Prove requester has modified a DNS record for the domain to claim the issue's cryptographic identifier (AID).
 Similar to FBAC "basic" or eIDAS "nonqual".
2 aka "silver" cryptographic proof of control + authz, legal accountability, tools; no claim about governance or competence
  1. Satisfy requirements for LoA 1.
  2. Prove the legal identity of the requester via a digital credential having eIDAS substantial assurance, or use a physical credential that meets ISO/IEC 2915 LoA2 or NIST IAL2 requirements.
  3. Prove cryptographically (e.g., using a GCD credential and/or a KERI delegated AID) that the requester was authorized by the org to request a credential for it.
  4. Use at least 1 witness for the org's AID.
 Similar to FBAC "medium", X509 extended verification, or eIDAS nonqual with deep vet. However, not a perfect analog; we are proving that the org has the tools to maintain their identity for a long time.
3 aka "gold"
  1. Satisfy requirements for LoA 2.
  2. Prove that the requester has legal signing authority for the org.
    3. Prove that the org has a multisig signing committee to manage risk and human turnover.
  3. Issue the credential in a ceremony where it is proved that there is no MITM between any two members of the signing committee, and between each member of the signing committee and at least one external observer.
  4. Require that the AID of the org use enough witnesses to reliably detect and recover from duplicity.
 This approximates FBAC "high" and eIDAS "QSeal", but goes slightly beyond. It maps directly to the LE vLEI defined by GLEIF.
4 aka "platinum" TBD, but could require use of hardware security and/or proof of specialized org attributes such as a security clearance. none

Schema

See org-vet.schema.json and also rules.json.

Governance Framework

These credentials are governed by rules to enhance assurance, discourage abuse, and keep use cases crisp. The current rules are stated in rules.json and are identified by SAID EFthNcTE20MLMaCOoXlSmNtdooGEbZF8uGmO5G85eMSF. New governance frameworks can be written that supplement these rules; see the gfw field in the schema. It is also possible to modify or override these rules, by placing a different value in the r field. The act of issuing or receiving a GCD credential constitutes binding acceptance of the rules.