Skip to content

Latest commit

 

History

History
76 lines (50 loc) · 3.73 KB

ovip-0011.md

File metadata and controls

76 lines (50 loc) · 3.73 KB
Raw
OVIP: 11
Title: VASP Registries
Author: David Riegelnig <[email protected]>
Discussions-To: https://community.openvasp.org/#narrow/stream/21-protocol-.2F.20ovip
Status: Accepted
Type: Standard
Created: 2020-06-11

Abstract

Virtual Assets Service Providers (VASPs) using the OpenVASP protocol establish their identity based on a self-assigned VASP Identifier whose uniqueness is ensured via the Index Contract.

The holder of the VASP Identifier can prove his authenticity as well as ownership of the respective VASP Contract by signing with the private key (see ovip-0003).

Those sending an OpenVASP Message to the holder of a specific VASP Identifier can therefore be ensured that only this holder will be able to receive and decrypt the Message when using the public keys (for transport and session layer) available from the respective VASP Contract for encryption.

This approach in combination with an identity-based routing (such as Ethereum Whisper) implements the basic principle that no registration with any central party is required to securely route messages and use the protocol on a technical level.

However, having full confidence in the link between the VASP Identifier and a real-world entity requires additional assurance, either through first-hand evidence or verification by a trusted third party.

The VASP Registry specification in this document defines a smart contract interface for how trusted third parties can provide a registry of claims (assertions) about VASPs via the VASP Identifier.

Definitions

VASP Identifier
Globally unique VASP identifier as specified in ovip-0002.

VASP Registry
Smart contract operated by a trusted third party providing access to claims about a VASP referenced by its VASP Identifier.

Credential
Claim about a VASP issued by a trusted third party via its VASP Registry.

Specification

1. Contract Interface

Conformant VASP Registries should implement the following function:

function getCredentialsRef
(
    bytes6 vaspId
)
    external virtual view
    returns (string memory credentialsRef, bytes32 credentialsHash);

Description:
Returns a tuple consisting of the reference to a Credential and the Keccak256 hash of the Credential about a VASP specified by its VASP Identifier (vaspID).

The reference being a pointer that allows to retrieve the actual Credential. However, the way how the Credential can be retrieved is defined by the respective VASP Registry and must be known to the processor calling the function.

Conditions:
vaspID is a valid VASP Identifier.

2. Credential Format

Credentials should be conformant to the W3C standard on "Verifiable Credentials" as specified in https://www.w3.org/TR/vc-data-model/.

Motivation

The OpenVASP protocol wants to facilitate an open framework for VASPs and trusted third parties to establish a web of trust. Standardizing the interface for VASP Registries fosters a broad ecosystem of such services.

Rationale

  • Encapsulating registry implementations behind a standardized smart contract interface eases integration for software providers building for the OpenVASP standard.
  • Using the VASP Identifier as input is consistent with its usage accross the protocol.
  • bytes32 output is chosen to match the Ethereum transaction hash as a natural identifier for the actual claim item (e.g. referring to Ethereum event log data).
  • W3C Verifiable Credentials are an excellent match given the principles of OpenVASP. They are flexible to encode all sorts of claims.

Backwards Compatibility

Specification proposes new functionality.