Skip to content

Latest commit

 

History

History
140 lines (110 loc) · 5.73 KB

ovip-0015.md

File metadata and controls

140 lines (110 loc) · 5.73 KB
OVIP: 15
Title: OpenVASP Credential
Author: David Riegelnig <[email protected]>
Discussions-To: https://community.openvasp.org/#narrow/stream/21-protocol-.2F.20ovip
Status: Accepted
Type: Standard
Created: 2020-06-21

Abstract

The OpenVASP Association maintains the OpenVASP Directory (Directory), a registry of VASPs whose identity and license status has been verified. For each VASP, the Directory provides a digitally signed proof of verification called OpenVASP Credential (Credential).

This OVIP specifies how Credentials are structured and how conformant implementations must interpret them.

Specification

1. Retrieving the Credential

Conformant implementations must retrieve the Credential directly from the Directory smart contract via the getCredentialRef() function (see ovip-0012) and must not rely on any other source.

2. Credential Integrity

Conformant implementations must verify the Credential's content using its hash available from the Directory smart contract or the corresponding event logs (see ovip-0012).

3. Credential Validity

The Credential is valid as long as it can be retrieved from the Directory. Revoked Credentials remain available from the Directory's event logs.

4. Credential Content

4.1. Credential Structure

The Credential is a "Verifiable Credential" as per W3C Recommendation (https://www.w3.org/TR/vc-data-model/) with an element structure as specified in the table below.

Level 1 Level 2 Level 3 Mult. Values
@context 1..1 https://www.w3.org/2018/credentials/v1
id 1..1 https://openvasp.org/verification
type 1..1 VerifiableCredential, OpenVASPCredential
issuer 1..1 https://openvasp.org
issuanceDate 1..1 String value as per RFC3339
credentialSubject 1..1
version 1..1 1.0
identity 1..1
type 1..1 VerifiedVASPIdentity_v1.0
vasp 1..1 Elements as specified in ovip-0013, 1.1
license 0..*
type 1..1 Name of recognized license or registration
country 1..1 Licensing country as per ISO 3166-1 alpha-2
authority 1..1 Licensing authority
regid 0..1 License number
agreement 0..*
type 1..1 NetworkAgreement_v1.0
mfamilies 1..1 Covered message families (e.g. TFR, ALL)

4.2. Example

{
	"@context": ["https://www.w3.org/2018/credentials/v1"],
	"id": "https://openvasp.org/verification",
	"type": ["VerifiableCredential", "OpenVASPCredential"],
	"issuer": "https://openvasp.org",
	"issuanceDate": "2020-08-01T15:23:24Z",
	"credentialSubject": {
		"version": "1.0",
		"identity": {
			"type": "VerifiedVASPIdentity_v1.0",
			"vasp": {
				"vaspid": "1000bb528777",
				"legal": {
					"name": [{
						"leg_name": "Example VASP AG",
						"leg_nametype": "LEGL"
					}, {
						"leg_name": "EgVASP",
						"leg_nametype": "SHRT"
					}],
					"ctry_reg": "CH"
				},
				"address": {
					"adr_type": "BIZZ",
					"street": "Musterstrasse",
					"bldg_no": "88",
					"postcode": "6300",
					"town": "Zug",
					"country": "CH"
				},
				"id": [{
					"id_id": "CH02035398520",
					"id_type": "RAID"
				}, {
					"id_id": "529900W6B9NEA233DS71",
					"id_type": "LEIX"
				}]
			}
		},
		"license": {
			"type": "VQFSRO",
			"country": "CH",
			"authority": "Financial Services Standards Association (VQF)"
		},
		"agreement": {
			"type": "NetworkAgreement_v1.0",
			"mf": "ALL"
		}
	}
}

5. Presentation Requirements

5.1. Credential States

Conformant implementations must present the state of Credentials to the user in a clear and obvious way using the mandatory labels in the table specified below.

Description Mandatory Label
Credential is valid VASP Verification valid
Credential was valid in the past, but was since revoked VASP Verification no longer valid
Credential's integrity cannot be verified VASP Verification incorrect
No Credential is available Unverified VASP

5.2. User Warning

Conformant implementations should interrupt and warn the user when interacting with a VASP whose Credential is other than valid.

5.3. Credential Details

Conformant implementations must display all Credential details to the user on demand.

Backwards Compatibility

Specification proposes new functionality.