# Enabling Travel Rule Interoperability

## Context

Existing approaches to the Travel Rule are limited by their reliance on closed architectures and lack of scalability and interoperability.

[Notabene proposed a lightweight, decentralized approach](https://notabene.id/post/proposed-solution-to-travel-rule-deadlock) to address these limitations by introducing a connecting fabric based on W3C Decentralized Identifier (DID) and W3C Verifiable Credential (VC) standard. These standards can address the discoverability and consistent identity assurance requirements, providing the necessary interconnectivity to bridge existing travel rule protocols ([OpenVASP](https://notabene.id/travel-rule-messaging-protocols/openvasp), [TRP](https://notabene.id/travel-rule-messaging-protocols/trp), [Shyft](https://notabene.id/travel-rule-messaging-protocols/shyft-network) and [Sygna](https://notabene.id/travel-rule-messaging-protocols/sygna-bridge)).

This proposed solution allows VASPs to easily onboard onto the network without the need for centralized coordination, permission, or fees. It’s designed to be scalable and avoid the need for implementers/adopters to pick a single travel rule protocol stack.

The purpose of this document is to outline the efforts involved in building out the above approach as a Verite work item. Source:

## Proposal

Assumptions (for now):
* Hosted wallet
* Generic discovery identity credentials (unbounded)

Specific work efforts/deliverables are outlined below.

### Effort 1: Define Beneficiary and Originator Identity Claim Format

**Overview**: Define standard data models for VASPs to exchange required identity information about beneficiary and originator

**Details:**
* Define format and required fields/properties
* Claims shall be based upon W3C VCs
* Claim must specify that beneficiary is a client of the issuer VASP
* Recommend beneficiary props be in IVMS format. This will enable discovery plus subsequent travel rule payload via [IVMS](https://intervasp.org/)
* Reference: [interVASP-data-model-standard-issue-1-FINAL.pdf](http://34.64.107.172/~vasp/wp-content/uploads/2020/05/IVMS101-interVASP-data-model-standard-issue-1-FINAL.pdf)
* Define (as needed) flexibility mechanism for use case or jurisdiction requirements
* Define VC vocabularies

Work in progress: https://hackmd.io/qSVHE6glQ1eRTqIycVnuHg?edit

### Effort 2: VASP identification (DD)

_Note: discovery not necessary_

**Goal**: Define a standard to identify VASPs with DIDs, defining a common set of metadata needed for unambiguous discoverability (in the DID Documents)

**Details**:

[See Draft](https://gitlab.com/OpenVASP/travel-rule-protocol/-/blob/master/extensions/vc-beneficiary-info.md)

* Clarify DID and DID Document contents
* [Notabene Draft](https://notabene.id/post/proposed-solution-to-travel-rule-deadlock) (#3)
* The VASP's DID document would include information on which protocols they support and the necessary parameters.
* Also must have an endpoint to get credentials about the VASP itself
* VASP due diligence claims
* Define format, schema (similar to above)
* VCs include self-attested claims and what auditors, e.g. TRISA, attest
* Based on [Wolfsberg](http://34.64.107.172/~vasp/wp-content/uploads/2020/05/IVMS101-interVASP-data-model-standard-issue-1-FINAL.pdf) - standardized FinSvcs Provider DD baseline:
* Includes operational info such as KYC standards complied with
* Can be self-attested, audited, GLEIF-confirmed, VASPnet-confirmed…
* Must be extensible for future features or optional extensions
* E.g. Proof-of-reserves hooks
* Interoperability profiles, as necessary
* Decentralized Identity Foundation (DIF) Presentation Exchange for VASP conveying required data to other VASP (i.e. certain fields like jurisdiction may be optionally required)
* Possibly, credential exchange protocol
* This is the method for VASP-to-VASP exchange of VASP DD credentials
* Could be bundled or separate
* E.g., see `VASPVerifiableCredentialService`

### Effort 3: VASP-to-VASP Messaging and Exchange Protocol

**Goal**: Once a VASP has discovered the other’s endpoint, it needs to initiate a secure request and declare the information it needs, while providing the information the other needs

**Details**:
* If using IVMS (see Effort 1), original credential can ensure beneficiary VASP knows who’s who (sidesteps some error cases for name-matching slight mismatches)
* IVMS is structure of data
* Approach: can delegate to existing TR protocols AND define new open protocol
* Clarify / Define standard message formats for describing travel rule requests and responses. Define VC envelope as needed
* Additive TRP: [Trust establishment; exchange of public credentials](https://verite.id/verite/patterns/travel-rule#part-2-trust-establishment-ie-exchange-of-public-credentials)

## To Figure Out

* Why would this even be interesting to existing TR protocols?
* The idea is that a more open alternative may be _forced_ upon them and here are easy-to-use patterns...
* Phasing and rollout
* Focus on bridging and discovery
* Downplay/be discrete about the additional VC protocol - maybe frame it as the “interop layer”/neutral solution to make clear that everyone can keep monetizing on VC issuance