In the nascent area of cryptocurrency and transactions of virtual assets, a new type of entity is slowly emerging called the Virtual Asset Service Providers (VASP). The most common example of a VASP today is the cryptocurrency exchanges, which support end-users in delivering cryptocurrencies (e.g. Bitcoins) from one blockchain address (public-key) to another. There are a number of growing pains for VASPs, especially in the light of the long history of inter-bank wire payments (e.g. correspondent banking) and the body of regulations that govern these kinds of banking activities.
Currently, many VASP businesses face various technical, operational and legal challenges which need to be addressed before the cryptocurrencies and virtual assets sector can begin to grow and mature. Some example of these challenges include:
The Travel Rule for virtual assets: The FATF Recommendation 15  requires VASPs to retain information regarding the originator and beneficiaries of virtual asset transfers. This includes (i) originator’s name; (ii) originator’s account number (e.g. at the Originating-VASP); (iii) originator’s geographical address, or national identity number, or customer identification number (or date and place of birth); (iv) beneficiary’s name; (v) beneficiary account number (e.g. at the Beneficiary-VASP).
FinCEN compliance requirements: The FinCEN rules for anti-money laundering (AML) from 2014  requires that customer due diligence (CDD) be performed for convertible virtual currencies .
Decreasing trust of consumers in institutions: Over the last decade there has been a continuing decline in trust on the part of individuals with regards to the handling and fair use of personal data [4, 5]. This situation has been compounded by the various recent reports of attacks and theft of data (e.g. Anthem , Equifax ).
Emergence of data privacy regulations: The enactment of the GDPR  in Europe has influenced the discourse regarding data privacy in other nations (e.g. the state of California followed with the CCPA ). Given the prominent role of data in the new digital economy, the emergence of a US federal privacy act cannot be ruled out .
Today many users possessing virtual assets (e.g. cryptocurrencies) expect asset transfers through VASPs to be confirmed or settled in a matter of seconds. However, the need for VASPs to exchange and validate customer information prior to asset transfers may impose delays on the settlement of transfers. Furthermore, VASPs do not as yet have an agreed mechanism to exchange their respective customer information in a secure and reliable manner.
We believe that this lack of an information exchange mechanism points to a more fundamental challenge facing the VASP community worldwide: namely the lack of trust infrastructures that are highly scalable and interoperable, which permit business-trust and legal-trust to be established for peer-to-peer transactions of virtual assets across different jurisdictions as part of global exchange networks.
There are several forms of trust infrastructures needed for VASPs, and in this chapter we discuss three forms or types of such infrastructures. The first is an information sharing infrastructure specifically for VASPs. The main purpose of a VASP information sharing infrastructure is to securely and confidentially share customer information related to transfers of virtual assets. Related to this network is the VASP identity infrastructure that permits VASPs and other entities to quickly ascertain the business legal status of other VASPs. Next is an attestation infrastructure that can support VASPs and asset insurers in obtaining better visibility into the state of customer wallets based on trusted hardware. Finally, there is a need for a claims infrastructure for customer data sources that integrates seamlessly into the existing user digital identity infrastructure.
The Financial Action Task Force (FATF) is an inter-governmental body established in 1989 by the ministers of its member countries or jurisdictions. The objectives of the FATF are to set standards and promote effective implementation of legal, regulatory and operational measures for combating money laundering, terrorist financing and other related threats to the integrity of the international financial system. The FATF is a “policy-making body” which works to generate the necessary political will to bring about national legislative and regulatory reforms in these areas.
With the emergence of blockchain technologies, virtual assets and cryptocurrencies, the FATF recognized the need to adequately mitigate the money laundering (ML) and terrorist financing (TF) risks associated with virtual asset activities. In its most recent Recommendation 15 , the FATF defines the following:
Virtual Asset: A virtual asset is a digital representation of value that can be digitally traded, or transferred, and can be used for payment or investment purposes. Virtual assets do not include digital representations of fiat currencies, securities and other financial assets that are already covered elsewhere in the FATF Recommendations.
Virtual Asset Service Providers (VASP): Virtual asset service provider means any natural or legal person who is not covered elsewhere under the Recommendations, and as a business conducts one or more of the following activities or operations for or on behalf of another natural or legal person: (i) exchange between virtual assets and fiat currencies; (ii) exchange between one or more forms of virtual assets; (iii) transfer of virtual assets; (iv) safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets; and (v) participation in and provision of financial services related to an issuer’s offer and/or sale of a virtual asset.
In this context of virtual assets, transfer means to conduct a transaction on behalf of another natural or legal person that moves a virtual asset from one virtual asset address or account to another. Furthermore, to manage and mitigate the risks emerging from virtual assets, the Recommendations states that countries should ensure that VASPs are regulated for AML and Countering Financing of Terrorism (CFT) purposes, and licensed or registered and subject to effective systems for monitoring and ensuring compliance with the relevant measures called for in the FATF Recommendations.
One of the key aspects of the FATF Recommendation 15 is the need for VASPs to retain information regarding the originator and beneficiaries of virtual asset transfers. The implication of note  is that cryptocurrency exchanges and related VASPs must be able to share the originator and beneficiary information for virtual assets transactions. This process – also known as the Travel Rule – originates from under the US Bank Secrecy Act (BSA - 31 USC 5311 - 5330), which mandates that financial institutions deliver certain types of information to the next financial institution when a funds transmittal event involves more than one financial institution. This rule became effective in May 1996 and was issued by the Treasury Department’s Financial Crimes Enforcement Network (FinCEN). This rule was issued by FinCEN concurrently with the new BSA record keeping rules for funds transfers and transmittals of funds.
Given that today a virtual asset on blockchain is controlled through the public-private keys bound to that asset, we believe there are other information (in addition to the customer and account information) that a VASP needs to retain in order to satisfy the travel rule [12, 13]:
Key ownership information: This is information pertaining to the legal ownership of cryptographic public-private keys. When a customer (e.g. originator) presents their public key to the VASP for the first time, there must be a “chain of provenance” evidence regarding the customer’s public-private keys which assures that the customer is the true owner. Proof of possession of the private key (e.g. using a challenge-response protocol, such as CHAP (RFC1994)) does not prove legal ownership of the public-private key.
Key operator information: This is information or evidence pertaining to the legal custody by a VASP of a customer’s public-private keys. This information is relevant for a VASP which adopts a key-custody business model in which the VASP holds and operates the customer’s public-private keys to perform transaction on behalf of the customer.
In the 2014 FinCEN Know Your Customer (KYC) requirements under the BSA , the proposed rules contained explicit customer due diligence (CDD) requirements and included a new regulatory requirement to identify “beneficial owners” of customers who are legal entities. It is worthwhile to note that the CDD requirements include conducting ongoing monitoring to maintain and update customer information and to identify and report suspicious transactions. Collectively, these elements comprise the minimum standard of CDD, which FinCEN believes is fundamental to an effective AML program.
The FATF definition of virtual assets means that VASPs – like traditional financial institutions – need to establish an effective AML and CDD program in the sense of FinCEN [2, 3]. We believe that VASPs must additionally obtain and retain the originator/beneficiary cryptographic key ownership information as a core part of monitoring the movement of virtual assets.
It is important to emphasize that a VASP as a business entity must be able to respond comprehensively to legitimate inquiries from law enforcement regarding one or more of its customers owning virtual assets (e.g. legal SAR inquiries/warrants). More specifically, both the Originator-VASP and Beneficiary-VASP must possess the complete and accurate actual personal information (i.e. data) regarding their account holders (i.e. customer). This need for actual data, therefore, precludes the use of advanced cryptographic techniques that aim to prevent disclosure while yielding implied knowledge, such as those based on Zero-Knowledge Proof (ZKP) schemes .
One of the key challenging issues related to the Travel Rule is the privacy of customer information once it has been delivered between VASPs. This problem can be acute when one VASP is located within a jurisdiction with strong privacy regulations (e.g. EU with GDPR ), while the other is located in a jurisdiction with an incompatible privacy regulations . More specifically, if a Beneficiary-VASP is located under a different legal jurisdiction (e.g. foreign country) observing weaker privacy regulations than the originator’s jurisdiction, there are no means for the originator to ensure her customer information is not leaked or stolen from that Beneficiary-VASP.
A core part of an information sharing infrastructure is a network shared among VASPs to exchange information about themselves and their customers. The notion of an out-of-band (off-chain) network for VASPs to share information about themselves and their customers was first proposed in  as part of the broader discussion within the FATF Private Sector Consultative Forum leading up to the finalization of Recommendation 15 in mid-2019. The idea of an information sharing network is not new, and the banking community established a similar network (i.e. the SWIFT network ) over two decades ago. Today this network is the backbone for global correspondent banking.
As such, similar to banking data networks, a “network” is needed for VASPs to securely exchange information about themselves and about their customers for Travel Rule compliance and other requirements. This information sharing network should be layered atop the proven TCP/IP Internet, in order to
There are several fundamental requirements for an information sharing network for VASPs (Figure 1):
Security, reliability and confidentiality of transport: The VASP information sharing network must provide security, reliability and confidentiality of communications between an Originator-VASP and Beneficiary-VASP. Several standards exists to fulfil this requirement (e.g. IPsec VPNs , TLS secure channels , etc.).
Strong end-point identification and authentication: VASPs must use strong endpoint identification and authentication mechanisms to ensure source and destination authenticity and to prevent (reduce) man-in-the-middle types of attacks. Mechanisms such as X.509 certificates [19, 20] have been used for over two decades across various industries, government and defense as a practical means to achieve this goal .
Correlation of customer information with on-chain transactions: There must be a mechanism to permit a VASP to accurately correlate (match) between customer information (exchanged within the VASP information sharing network) and the blockchain transactions belonging to the respective customers. This must be true also in the case of batch transactions performed by a VASP (e.g. in the commingled accounts business model).
Consent from originator and beneficiary for customer information exchange: Unambiguous consent  must be obtained by VASPs from their customers with regards to the transmittal of customer personal information to another VASP. Explicit consent must also be obtained from the beneficiary for receiving asset transfers from an originator. That is, a Beneficiary-VASP must obtain consent from its customer to receive asset transfers into the customer’s account.
Efforts are currently underway to begin addressing the need for a VASP information sharing network to support VASPs in complying to the various aspects of the Travel Rule (see [21, 22]). A standard customer information model has recently been developed  that would allow VASPs to interoperate with each other with semantic consistency.
We use the term “VASP information sharing” to denote broadly the interaction between VASPs in the context of the delivery of subject (originators, beneficiaries and VASPs) information related to a virtual asset transfer. The VASP information sharing network must address the various aspect of communications between VASPs: (i) the definition of the data being transferred; (ii) the reliable delivery at the VASP application layer; (iii) the interoperability of the delivery layer (e.g. TCP/IP; intra-chain P2P delivery mechanism); (iv) external representation of identifiers and keys, and the legal identity of entities who own/control those identifiers and keys.
Figure 2 illustrates one possible logical layered architecture of the VASP information sharing network. These are described as follows. Similar to the layered architecture of the Internet [24, 25], one of the main goals of a given layer is to support the function of an upper layer by abstracting functions (hiding details of this layer) to the higher layer.
We adopt the terminology for blockchain technology from NIST . For definition of virtual assets, we adopt those defined by the FATF Recommendations [1, 11] and FinCen . Additionally, we may introduce qualifications to the terms as a means to increase the clarity of discussion.
Virtual Asset Service Providers (VASP): Virtual asset service provider means any natural or legal person who is not covered elsewhere under the FATF Recommendations 15 .
Messaging protocol: The mechanism used within the VASP information sharing network to deliver a message (e.g. bytes of any length) from one VASP to another. A standard for the precise information to be communicated using the protocol has bee defined in .
Subject: The person or organization (legal entity) involved in a virtual assets transfer event . The subject (whose information is being delivered) can be the following: originator, beneficiary, Originator-VASP, Beneficiary-VASP.
Claim (Assertions): A digitally signed statement from an authoritative entity that is attesting to the accuracy and truthfulness of the information contained regarding a subject. In this case the signer is the VASP, and the subject can be the VASP itself or a customer of the VASP. Several formats for claims or assertions have been standardized (e.g. [27, 28, 29]).
Claims Provider: An authoritative entity that issues signed assertions or statements regarding a subject (person or organization). By digitally-signing a claim, the Claims Provider is attesting to the truthfulness of the assertion. The assertion itself may be embellished by additional information (e.g. context indicator, trustworthiness score, date of issuance, expiration data, data-source indicators, algorithm identifiers, etc).
Address (blockchain-address): A short, alphanumeric string derived from a user’s public key using a hash function, with additional data to detect errors. Addresses are used to send and receive virtual assets .
Virtual assets blockchain: The blockchain system within which the transfer of virtual assets occur between two entities (e.g. originator to beneficiary; Originator-VASP to Beneficiary-VASP; etc).
VASP network-address: The network-address used by VASPs to deliver information regarding a subject in a virtual asset transfer, as well as other VASP system related parameters.
Transport address: The ephemeral address used at the delivery layer (eg. IP address).
Legal Entity Identifier: The Legal Entity Identifier (LEI) is is a 20-character, alpha-numeric code, to uniquely identify legally distinct entities that engage in financial transactions .
The top-most layer of Figure 2 pertains to the information or data regarding subjects (originators; beneficiaries; VASPs) involved in a given virtual asset transfer. The goal of this layer is simply to communicate data and information from one VASP to another in a reliable and accurate manner following a standardized syntax, such as OpenVASP . Thus, for example, issues such as an asset transfer request/response and transfer-confirmations  or Invoice request and payment request  must be handled by constructs at this layer.
The syntactic definition of the data and information being communicated must be defined using a separate information lexicon and data model such as the InterVASP proposal . Data or information obtained by a VASP from another source entity must be delivered in a standard assertions or claims format that is signed by that source. This allows the receiving VASP (e.g. beneficiary VASP) to know its origins/provenance and to assess the veracity of the signed claims or assertions.
At the end-point of the transfer of subject data and claims are VASPs, which as legal entities are bound by certain legal regimes. For VASPs, two key questions (among others) that need to be addressed in this layer are: (i) identity-authenticity of the VASP entity at the opposite end of the interaction; and (ii) the legal status of that VASP (assuming it hs been correctly identified and authenticated).
At this layer, identity management protocols may play a crucial role in identifying and authenticating entities with whom a VASP interacts. Several identity management protocols have been standardized and are in wide deployment today (e.g. SAML2.0 , OpenID-Connect ). The association or binding between a digital identity and the owner of that identity in the legal context also occurs at this layer. Legal constructs, such as the Legal Entity Identifier (LEI)  are captured and represented at this layer.
The digital identity layer relies on cryptographic keys and protocols which allow entities to prove their digital identity. Thus, at this layer the management of private-public keys are crucial (e.g. see [33, 34, 35]). The protocols to negotiate mutual session-keys and establish secure end-to-end encrypted channels also occur at this layer (e.g. ECDH; TLS/SSL).
Mechanisms and protocols to prove legal ownership of public (private) keys correspondingly occur in this layer. These can be via certification performed by 3rd parties (e.g. Certification Authorities) who issue public-key certificates (e.g. X.509 standard [36, 37, 20]).
The bottommost of the layers architecture is the actual message delivery mechanism and protocols that underlie the VASP-to-VASP interaction. There a number of design principles that should be observed in the delivery of claims:
Independence of VASP information sharing network from virtual asset transfer mechanism: The messaging mechanism (protocol) used between VASPs must not be dependent on any specific virtual assets blockchain. VASPs must be able to communicate directly (out of band) with other VASPs (pair-wise direct), without dependence on the asset blockchain system which they employ to transmit virtual assets. This ensures that as new blockchain technologies emerge/evolve, the VASP information sharing infrastructures can support new blockchain systems.
Default messaging channel: There must be a default mechanism by which two VASPs who wish to interact directly can establish pair-wise secure channel. VASPs must have the freedom to initiate and negotiate a pairwise secure channel with another VASP in an unmediated fashion. However, there are circumstances in which a common method cannot be found (e.g. both parties suggest incompatible protocols). To addresses such cases, a default mechanism must defined to which both parties must resort (e.g. plain TCP/IP using TLS1.3).
Default channel-protection negotiation mechanism: There must be a default mechanism by which two VASPs who wish to interact directly can establish security parameters to secure their shared messaging channel. We suggest using the standard key establishment protocols (e.g. ECDH protocol) regardless of the ensuing messaging protocol being used (e.g. Whisper in OpenVASP , SSL).
A core part of the VASP information sharing infrastructure is a VASP trusted identity infrastructure that permits VASPs to prove their identity, public-key(s), and legal business information.
A trusted identity infrastructure must address the various challenges around VASP identities and provide the following types of mechanism:
Discovery of VASP identity and verification of business status: Mechanism are needed to permit any entity on the Internet to ascertain whether a virtual asset service provider is a regulated VASP within a given jurisdiction. An Originator-VASP must be able to easily locate the identity information for Beneficiary-VASP and to rapidly determine the business and legal status of that Beneficiary-VASP (vice versa).
Discovery and verification of VASP public-keys: Mechanism are needed to permit any entity on the Internet to ascertain whether a given public-key legally belongs to (operated by) a given VASP.
Discovery and verification of VASP service endpoints: Mechanisms are needed to permit a VASP to ascertain whether it is connecting to the legitimate service endpoints (e.g. URI) of another VASP (and not a rogue endpoint belonging to an attacker).
Discovery of VASPs using customer identifiers: Mechanisms are needed to permit a VASP to search and discover a binding (association) between a customer user-friendly identifier (e.g. email address) and the VASP (one or more) that may hold an account for that customer.
The problem of discovering and verifying service provider public-keys and service endpoints was faced by numerous online merchants nearly two decades ago. For the end-user (i.e. home consumer) it was increasingly difficult to distinguish between a legitimate service provider (e.g. online merchant) from rogue web-servers that mimic the look-and-feel of legitimate merchants. In response to a growing trend of man-in-the-middle attacks, a number of browser vendors established an alliance in the late 2000s – called the CA/Browser Forum (CAB Forum) – that brought together browser vendors and X.509 certification authorities (CA). The CAB forum, as an industry standards defining organization, published a number of industry technical specifications referred to as Extended Validation (EV) identity certificates . The overall goal was to enhance the basic X.509 certificate [19, 20] with additional business related information regarding the subject (i.e. the online merchant). The CA that issues EV-certificates must perform the various information background checks regarding the subject, to ensure that the subject was a legitimate business. Correspondingly, the browser vendors supported EV-certificates by pre-installing a copy of the root CA certificate of all compliant CAs into their browser software.
We believe a similar approach is suitable for fulfilling a number of the VASP requirements discussed above. Some of the subject (VASP) business information to be included in the VASP identity EV-certificate could be as follows :
Organization name: The Organization field must contain the full legal name of the VASP legal entity controlling the VASP service endpoint, as listed in the official records in the VASP’s jurisdiction.
VASP Alternative Name Extension: The Domain Name(s) owned or controlled by the VASP and to be associated with the VASP’s server as the endpoint associated with the certificate.
VASP Incorporation Number or LEI (if available): This field must contain the unique Incorporation Number assigned by the Incorporating Agency in the jurisdiction of incorporation. If an LEI number  is available, then the LEI number should be used instead.
VASP Address of Place of Business: This is the address of the physical location of the VASP’s Place of Business.
VASP Jurisdiction of Incorporation or Registration: This field contain information regarding the Incorporating Agency or Registration Agency.
VASP Number: This is the globally unique VASP number, if used (see OpenVASP ).
VASP Regulated Business Activity: Currently, no formal definition of business activity specific for VASPs have been defined. Note that in reality VASPs may operate different functions in the virtual assets ecosystem (e.g. crypto-exchanges, virtual asset based fund managers, stablecoin issuers, etc.).
EV Certificate Policy Object Identifier: This is the identifier for the policies that determine the certificate processing rules. Such policies could be created by the organization using the certificate, such a consortium of VASPs (see section 5.3 below).
For assets in commingled accounts managed by a VASP, the asset transfer on the blockchain is performed by the VASP using its own private-public key pair on behalf of the customer. The customer holds no keys in the commingled cases. We refer to these private-public keys as the VASP transactions signing-keys, and we refer to corresponding certificate as the transactions signing-key certificates. The purpose of signing-key certificates is to certify the ownership of the private-public keys as belonging to the VASP. A given VASP may own multiple transactions signing-keys and therefore multiple signing-key certificates.
Because a VASP must stand behind the customer information it provides to other VASPs, any claims  or assertions  that a VASP produces about its customers must be digitally signed by the VASP. We refer to these private-public keys as claims signing-keys, and we refer to corresponding certificate as the claims signing-key certificates.
It is crucial for a VASP that these three (3) key-pairs be distinct. This is because the key-usage purpose of the keys are different, and each key may have differing lifetime durations. Depending on the profile of a transactions signing-key certificate and the claims signing-key certificate, they may include the serial number (or hash) of the identity EV-certificate of the VASP. This provides a mechanism for a recipient to validate that the owner of these two certificates is the same legal entity as the owner of the VASP identity EV-certificate.
In order for VASPs to have a high degree of interoperability – at both the technical and legal levels – a consortium arrangement provides a number of advantages for the information sharing network. Members in a consortium are free to collectively define the common operating rules that members must abide by. The operating rules become input matter into the definition of the legal trust framework which expresses the contractual obligations of the members.
A well-crafted set of operating rules for a VASP information sharing network provides its members with the several benefits. First, it provides a means for the members to improve risk management because the operating rules will allow members to quantify and manage risks inherent in participating within the network. Secondly, the operating rules provides its members with legal certainty and predictability by addressing the legal rights, responsibilities, and liabilities of participating within the network. Thirdly, the operating rules provides transparency to the members of the network by having all members agree to the same terms of membership (i.e. contract). Since the operating rules is a legal contract, it is legally enforceable upon all members. Finally, a set of operating rules which define common technical specifications (e.g. APIs, cryptographic functions, certificates, etc.), for all the members provides the highest chance of technical interoperability of services. In turn, this reduces overall system-development costs by allowing entities to re-use implementations of those standardized technical specifications. Several examples of consortium-based operating rules exist today (e.g. NACHA , OIX ).
Using the identity EV-certificates mentioned above as an example, the common operating rules would define the technical specification (profile) of the EV-certificate (e.g. cryptographic algorithms, key lengths, duration of validity, issuance protocols, revocation protocols, etc.), as well as the legal information that must be included in the EV fields of the certificate (e.g. legal incorporation number, LEI number, place of business, etc.).
Business interoperability can only be achieved if all members of the information sharing network observe and implement these common operating rules, and if there is legal and monetary liability for not doing so. This approach is not new and is used for group peering agreements among IP routing service providers (i.e. access ISPs and backbone ISPs). Technological interoperability of identity EV-certificates dictates that members of the information sharing network participate under a common certificate hierarchy, that is rooted at the consortium organization. This is shown in Figure 3, where the consortium becomes the Root-CA for the certificates issued to all VASPs in the consortium organization.
Certificate hierarchies have been successfully deployed in numerous organizations, ranging from government organizations , to financial networks , to mobile devices and networks , to consortiums of cable-device manufacturers . An example of a consortium that brings together device manufacturers (i.e. Cable Modem and Set Top Box vendors) and service operators (i.e. regional cable access providers) is Cable Laboratories (CableLabs). The combined type of membership in CableLabs permits cable operators to detect and isolate counterfeit devices and provide end-to-end protection for valuable content (e.g. movies). This combined approach may be relevant for VASPs dealing with customer wallet devices.
There is today a need for crypto-asset management systems to be integrated seamlessly with existing identity management infrastructure functions, including identity authentication services, authorization services, and consent management services.
Currently most users employ their email address as a form of user identifier in the context of obtaining services on the Internet. Many of these identifiers do not represent the user’s full person (core) identity , and have short-term or ephemeral value (i.e. identifier can be replaced with a new one). Typically the entities who issues the identifiers are email providers and social media platform providers. The industry jargon used to describe them (rather inaccurately) is Identity Provider (IdP). Besides providing email-routable identifiers to users, the identity provider’s role in the identity ecosystem is to provide mediated authentication services and credential-management on behalf of the user .
Mediated authentication – such as single sign-on (SSO) – provides convenience for the user by obviating the need for them to authenticate multiple times to each online service provider (e.g. online merchant) they visit. The online merchants redirects the user temporarily to the IdP for user-authentication, and upon success the user is returned back to the merchant.
The predominance of email-identifiers for users is a matter of consideration for VASPs because some users may wish to use their email address as the main identifier for account-creation at the VASP. They may also seek to use the email identifier of a beneficiary in the context of asset transfers. Furthermore, a user may have multiple accounts, each at different VASPs and each employing different email identifiers obtained from different IdPs.
An interesting approach is used in the PayID scheme  where the user is identified using a string similar to the addr-spec identifier (RFC5322), but with the “@” symbol replaced by the dollar sign (“$”) while retaining the local-part and the domain-part. For example, if Alice has an account at the PayID provider (e.g. ACMEpay.com) then her PayID identifier would be alice$acmepay.com.
The matter of user identifiers is important not only from the customer usability perspective, but also from the need for interoperability of services across VASPs within the information sharing network. When an Originator-VASP employs a user-identifier scheme to identify an originator and beneficiary, then the Beneficiary-VASP must have the same syntactic and semantic understanding of the identifier scheme. That is, both VASPs must be identifying the same pair of originator and beneficiary customers. Thus, another use of the VASP information sharing infrastructure discussed previously is for VASPs to exchange the list of identifiers of their respective customers. This can be achieved by each VASP in the network employing an Identifier Resolver Service (server) that is accessible to other VASPs in the network (see Figure 4).
Some of the general requirements for a VASP resolver service are as follows (non-exhaustive):
Support for multiple user-identifiers: The resolver service must permit multiple types of user-identifiers to be associated with the customer of the VASP.
Fast lookup for VASP determination: The resolver service must support fast look-ups or searches based on an identifier string by other VASPs in the network. Such look-ups may be part of an asset-transfer request from a VASP’s customer and any delays in identifying the Beneficiary-VASP may add to the overall transfer settlement time as perceived by the customer.
Protected service APIs: The service endpoint APIs (e.g. RESTful, PubSub, etc.) of the resolver service must be protected. A caller VASP must be authenticated and authorized to use the APIs.
Validation of user-identifier to IdP: Optionally, for every user-identifier string submitted (added to) by a customer to their account at the VASP, the resolver service of the VASP should validate the string to its original issuer (if it was not the VASP). Thus, if customer Alice wishes to employ her email address email@example.com then the resolver service should seek to validate that Alice is known to the provider IdP1.
Figure 4 illustrates that both Alice and Bob can be recognized using three different means: (i) their email address issued by an IdP (e.g. firstname.lastname@example.org); (ii) their PayID address managed by a VASP (e.g. alice$ovasp.com); or (iii) their bare public-keys (e.g. alice-pubkey).
Using Figure 4, consider the example of Alice who wishes to transfer virtual assets to Bob, but who only knows Bob’s email address (e.g. email@example.com). Alice does not know Bob’s public-key or Bob’s VASP. This means that Alice’s Originator-VASP must query its resolver service – as shown in Step 2(a) and Step 2(b) of Figure 4 – to discover which other VASPs in the network may know of the string firstname.lastname@example.org (i.e. uses the string in an account). Assuming the resolver service returns a positive response (i.e. VASP-identifier or VASP-number found), the Originator-VASP can begin inquiring to that VASP about Bob per the Travel Rule, as summarized in Step 3 and Step 4 of Figure 4.
Note that the resolver service of the Originator-VASP may return more than one possible Beneficiary VASP-identifier or VASP-number. This could mean that Bob has an active account at each of these VASPs (each possibly using a different private-public key pair). In such cases, the Originator-VASP may need to request further information (regarding Bob) from Alice.
It is worth noting that that identifier resolvers are not new, and several resolver protocols have been standardized and have been in wide deployment for over two decades now (e.g. Domain Name Service (RFC1035), Handle System (RFC3650), etc.). As such, the nascent VASP industry should consider using and extending these well-deployed systems, instead of designing something from scratch.
In general, we believe that a VASP resolver service should not return customer public-keys in the first instance in order to preserve customer privacy.
The purpose of the VASP resolver service is to aid other VASPs in determining whether an entity (person or organization) is a customer of one (or more) of the VASPs in the network. That is, the resolver service is aimed at solving the VASP discoverability problem: namely to look-up VASP identifiers (VASP-numbers) in order to engage that VASP.
Secondly, the information (metadata) about the association between a user-identifier and a VASP is less revealing than the association between a user-identifier and a public-key. As we mentioned before, user-identifiers (e.g. email addresses) associated with a customer account at VASP can be changed by the customer at any time without impacting the virtual assets bound to the customer’s public-key. In contrast, a change to the customer’s public-key is visible on the blockchain system.
Finally, different VASPs may employ different business models (e.g. key-custodian, commingled funds (accounts-only), regulated customer wallets). As such, in some cases (commingled funds) there is in fact no unique public-key associated with a given customer.
In order for VASP resolver services to scale-up, the VASPs must federate their resolver services under a common legal framework (i.e. the consortium model discussed above). A federation agreement allows VASPs to share customer identifier information (as known to the VASP) over the information sharing network. Indeed, this is one of the main purposes of the network.
For example, using the information sharing network, VASPs can regularly (e.g. overnight) exchange knowledge about each other’s customer identifiers. This is shown in Figure 4 in Step (a) and Step (b) that runs between the VASP resolver services.
Although the precise protocol is beyond the scope of the current work, in the simplest form the exchange of customer identifier information between VASP resolver services can consists of pairs of VASP-identifier value and customer-identifier values (i.e. list of customer-identifiers as known to the VASP):
VASP-identifier, Customer-id-1, Customer-id-2, . . . Customer-id-N
This approach is akin to IP route Link State Advertisements (LSA) used within some link-state routing protocols (e.g. OSPF (RFC2328)). In this case, a VASP is “advertising” its knowledge of customers bearing the stated identifiers.
The exchange of customer identifier information between two VASP resolver services must be conducted through a SSL/TLS secure channel established using the VASP X.509 EV-certificates to ensure traffic confidentiality and source authenticity.
In some cases, static attributes regarding a customer (e.g. age, state of residence, driving license, etc) can be obtained from authorized entities (e.g. government departments) in the form of asserted claims in one format or another [27, 29], with a fixed validity period. Within the identity industry, entities which issue signed assertions or claims are referred to as the Claims Provider (CP). A given customer of a VASP may already be in possession of a signed claim (e.g. driving license number) from an authoritative CP (e.g. Department of Motorized Vehicles), where the claim signature is still valid. The customer may keep a copy of the signed claim in the customer’s personal Claims Store (e.g. mobile device, home server, cloud storage, etc.). The customer could provide its VASP with a copy of the claims, or the customer may provide its VASP with access to the customer’s claims store.
There are several requirements and challenges for VASP access to claims store managed by the customer:
Customer-managed authorization to access claims-store: Access to the customer’s claims-store must be customer driven, where access policies (rules) are determined by the customer as the claims owner.
Consent-receipt issuance to VASP: The customer’s claims-store must issue a consent-receipt  to the VASP which acts exculpatory evidence covering the VASP.
An extension to the OAuth2.0 framework  called the User Managed Access (UMA) protocol [48, 49] can be the basis for customer-managed access to the claims store. In the example of Figure 5, the Originator-VASP is seeking to obtain signed claims regarding the originator customer (Alice) located in her claims store. Access polices have been set by Alice in Step (a). In Step 1 Alice provides her VASP with the location of this service provider. When the VASP reaches the UMA Service Provider (Step 2) – which acts as the authorization server in the OAuth2.0 and UMA context – the VASP is provided with authorization-token that identifies the specific claims the VASP is authorized to fetch (Step 3). The VASP wields the authorization-token to the claims-store (Step 4). The VASP obtains access to the relevant claims and is provided with a consent-receipt by the claims-store (Step 5).
A claim-store can be implemented in several ways. For example, it can be a Resource Server under the control of the CP, it can reside on Alice’s own mobile device, it can be placed in a cloud-based Trusted Execution Environment (TEE) , or it may implemented in a decentralized file system such as IPFS/Filecoin  based on a decentralized identifier (DID) scheme .
Although not directly relevant to the problem of deriving insights (claims) from data in a privacy-preserving manner, more recently there have been efforts to use blockchain technology to enable to the user to better control access to end-points on the Internet where signed claims may reside.
Referred to as Decentralized Identifiers (DID) , the basic idea is that the user would “register” to the blockchain a DID-record containing specific end-point configuration information (e.g. URLs and APIs) on the Internet where a requesting party can obtain information about the user (e.g. location of a store of signed claims). The record on the blockchain is digitally signed by the user, indicating that it is the user who self-declares the information about the service endpoint to be true. Since the user holds the matching private key, later if the user seeks to update the DID-record the user can simply replace it with a newer record (with a newer timestamp).
The idea of a DID as a persistent identifier follows from a long history of efforts on persistent and resolvable digital identifiers on the Internet. The most prominent of these identifier schemes is the Digital Object Identifier (DOI) , with its accompanying Handle resolver system . Similar in protocol-behavior to the DNS infrastructure, the DOI and Handle provide for an efficient look-up of copies of files (e.g. library catalog entries) stored at repositories all over the Internet. Today the DOI and Handle system have been successfully deployed at a wide scale for over a decade (e.g. for publications and library records).
The use of a DID is illustrated in Figure 6. Here in Step (1), in addition to the request to the VASP to transfer assets, the subject (customer originator) provides the VASP with a DID structure (either a public DID or pair-wise DID). The VASP resolves the DID value (via the blockchain or DID resolver) in Step (3A), which brings the VASP to the correct Claims Provider – who holds the subject’s claims - in Step (3B). The Claims Provider responds by delivering the signed claims in Step (4).
Although the DID/blockchain approach is useful for certain use cases (e.g. users self-managing their public keys), in the context of providing relying parties (i.e. VASPs) with truthful and accurate information about a subject in a privacy-preserving manner, the role of DIDs remain unclear .
Since the issuance of FATF Recommendation 15  there have been efforts to develop standards to support VASPs in complying to the FATF and Travel Rule in the context of virtual assets transfers.
The OpenVASP  effort borrows from existing modern payments standards, re-casted for the context of cross-VASP exchanges of information. The goal of OpenVASP is to establish a shared communications protocol for VASPs to exchange virtual asset transfer information, as required by the FATP Recommendations. A related approach is the Travel Rule Information Sharing Architecture (TRISA)  which seeks to develop a peer-to-peer mechanism for complying with these regulations. Finally, several organizations in the nascent virtual assets industry are collaborating to create an InterVASP data model for use in the submission of required originator and beneficiary information by originator VASPs to beneficiary VASPs respectively .
As mentioned previously, the Travel Rule requires an Originator-VASP to transmit the originator customer information to the Beneficiary-VASP (and vice versa). In general, this means VASPs sharing verified information about customers, which are typically static attributes about the customer (e.g. age, address, citizenship, etc.)
However, in the broader context of the FinCEN Know Your Customer (KYC) requirements , VASPs may be required to “know more” about their customers beyond the verified attributes demanded by the Travel Rule. VASPs therefore may need to conduct ongoing monitoring to maintain and update customer information, and to identify and report suspicious transactions. This, introduces another dimension of the customer relationship of a VASP, namely the need for a VASP to preserve the privacy of its customers in performing its KYC and CDD processes.
Today, in order to fulfill the need for ongoing monitoring of a given subject (person or organization), data analytics can be performed in order to identify certain trends or to pinpoint certain anomalies. Extensive data analytics can be performed only of data is readily accessible. In reality, however, today data regarding a subject is typically stored (siloed) within different institutions across different sectors of industry (e.g. financial data, health data, social platform behavioral data, etc.). Furthermore, each of these data repositories may be operating under different regulatory jurisdiction that make it difficult to combine these data in order to derive better insights . Thus, today we live in a kind of paradox: huge amounts of digital data are increasingly being accumulated, but usage for the betterment of individuals and communities are increasingly being hampered by various constraints.
With this backdrop, we believe that the MIT Open Algorithms (OPAL)  paradigm (discussed in the previous Chapters) may provide a path forward for VASPs and their Data Providers to work together to fulfill the CDD requirements while preserving customer data privacy:
KYC data sources of known provenance: Instead of a VASP collecting (hoarding) data about customers – often data which is obtained from third party data aggregators and which therefore will have weak or unknown origins – the VASP could establish a business relationship with the various Data Providers that specialize in certain types of strongly provenance data.
For example, a mobile network operator (i.e. mobile Telco) will be in possession of mobility data of known province because the data was generated by the operator’s own network elements (e.g. mobile cell towers).
Data Providers to executing vetted algorithms for insights: Many Data Providers maybe regulated in their domains and thus may be prohibited from providing data directly to external entities (i.e. VASPs). However, the Data Provider are able to internally execute algorithms in their back-end infrastructure to yield insights that are relevant to VASPs.
For example, private blockchain networks may possess data about a customer. This customer (person, organization) may be a customer of a VASP who is not a member of the private blockchain. The private blockchain governance may be prohibited from exporting this data to an external VASP, but they may be able to run analytics on the private ledger and share the resulting insights with an external VASP.
Customers consent for algorithm execution: A key aspect of the OPAL approach is that subject (customer) consent by default means permission to execute an algorithm, which is different from the current industry interpretation of “consent” (typically meaning permission to export or copy data out of the repository).
The OPAL approach has been piloted in Colombia and Senegal in 2017-2018 in the context of preserving privacy related to research using mobility data in those countries . A commercial implementation of OPAL for sharing of insights among financial industry entities is currently underway. An extensive discussion of OPAL is out of scope and has been treated elsewhere (e.g. see [59, 61]).
For many Data Providers (data holders) the open algorithms approach provides the most practical solution that does not require data providers to give up data – which is core to their business. In many circumstances, the requesting party (i.e. VASPS) simply need attributes and insights about a subject, and not raw data about the subject. As such, for many data holders the open algorithms paradigm may offer them new sources of revenue through the creation of algorithms to match the data in their possession, and by making these resulting insights available (e.g. as claims) to fee-paying customers (i.e. VASPs).
Greater effect is created when data providers from distinct industry verticals (e.g. banking & finance, health, telco, etc.) collaborate to achieve deeper insights about subjects. These deeper insights are what KYC and CDD programs require in the context of virtual assets and VASPs. We refer to a coalition or consortium of cross-industry data providers as Data Providers Trust Networks (see Figure 7). For the nascent VASP industry, collaboration with these data providers trust networks may be crucial is order to obtain access to these insights based on the open algorithms approach. In this way VASPs can obtain insights and attributes based on data of high-provenance, without needing to resort to third party data brokers/aggregators .
Figure 7 illustrates the notion of data providers trust networks supplying insights and attributes in a privacy-preserving manner using the open algorithms approach. The interface to the VASP (as the requesting party) is the Claims Provider service. In Figure 7, before the VASP is permitted to engage the Claims Provider service, the VASP as a relying party must first be authenticated and be authorized by the Authentication Service (AS). This is shown in Step (1) of Figure 7. The VASP is permitted to choose only from a published list of vetted algorithms. In Step (2) the VASP submits a request to the Claims Provider. Responses coming back from the data providers are collated by the Claims Provider and packaged in the form of a claim or assertion using the relevant format (e.g. [27, 29]). The claims or assertions are digitally-signed by the Claims Provider, and then transmitted to the VASP in Step (3). A copy of all issued claims or assertions are also placed in the claims store of the subject located, for example, within the Personal Data Store (PDS) [63, 64] of the subject. The copies of signed claims in the subject’s PDS claims-store allows the subject to independently make use of the claims for other purposes – which is consistent with the recommendation of the 2014 WEF report on personal data .
With the increase in the number of individuals and organizations holding private-public keys bound to virtual assets on a blockchain, there is an increased risk of the loss and/or theft of private-keys. VASPs who are custodians of a customer’s private-public keys and VASPs who employ their own keys to transact on behalf of customers face the problem of key management. As such, the use of electronic wallets based on trusted hardware – such as the Trusted Platform Module (TPM) chip  that offers key-protection may increasingly become a necessity for VASPs for their own business survival. Funds insurance providers  may seek to obtain evidence of the use of trusted hardware by VASPs and their customers. This brings to the foreground the challenge of establishing an attestation infrastructure for VASPs that assists them in obtaining greater visibility into the state of wallets implemented using trusted hardware.
In the following we use the term regulated wallet to denote a wallet system (hardware and software) that is in possession of a customer of a supervised (regulated) VASP [67, 68]. We use the term private wallet to denote a wallet system belonging to an unverified entity . In some cases, a VASP may decline to perform an asset-transfer to a public-key thought to be controlled by a wallet simply because the wallet-holder information is unattainable by a VASP, despite the VASP querying other VASPs in the information sharing network.
We use the term attestation to mean the capability in some trusted hardware to provide evidence (proof) that a device (platform) using the trusted hardware can be trusted to correctly and truthfully report the internal state of the device . The information reported is signed by the trusted hardware using an internal private-key that is non-readable by external entities and non-migrateable (i.e. cannot be extracted) from the trusted hardware. Thus, the recipient (e.g. a verifier) of the evidence obtains assurance that the signed report came from a particular device with the specific trusted hardware [70, 71]. These features provides interesting capabilities for VASPs in addressing some of their key management challenges, as well as AML/FT compliance needs.
For VASPs and asset insurance providers, there are several types of attestation evidence information that can be obtained from a wallet regarding keys used to sign asset-related transactions on the blockchain. The type of attestation evidence is dependent on the specific type trusted hardware but generally consists of the following :
Key creation evidence: The trusted hardware used in a wallet must have the capability to provide evidence regarding the origin of cryptographic keys held by the hardware. More specifically, it must be able to attest as to whether it generated a private-public key-pair internally or whether the key-pair was imported from outside.
Key-movability evidence: The trusted hardware used in a wallet must have the capability to provide evidence as to whether a private-key is migrateable or non-migrateable . This evidence permits the VASP to perform risk-evaluation regarding the possibility that the wallet holder (i.e. its customer) has dishonestly exported a copy of private-key to another wallet (and then use the key-pair in an unregulated manner).
Wallet system stack composition evidence: The trusted hardware used in a wallet should have the capability to provide evidence of the software stack present in the wallet [70, 71].
A given VASP may demand that customers use only approved wallets based on suitable trusted hardware. The VASP may also demand customers to create and use new key-pairs in the trusted hardware for all transactions (i.e. from the time the user becomes a legal customer of the VASP). This strategy provides the VASP with a clear line of responsibility and accountability under the Travel Rule with regards to customer-originated transactions. The VASP has exculpatory evidence regarding the on-boarding of the new customer and the start of use of the new key-pair.
Figure 8 provides an overview of wallet attestation, where the beneficiary (Bob) is the holder of a regulated wallet employing trusted hardware. In Step (1) the originator (Alice) requests her Originator-VASP to transfer virtual assets to Bob’s public-key. The Originator-VASP interacts with the Beneficiary-VASP to exchange customer Travel Rule information (Step (2)), including requesting the Beneficiary-VASP to obtain attestation evidence from Bob’s wallet (Step (3)). In Step (4) the Beneficiary-VASP delivers the customer account information and wallet attestation evidence to the Originator-VASP.
If the Originator-VASP is satisfied with the customer account information and wallet attestation evidence, the Originator-VASP performs the asset transfer to Bob’s public-key on the blockchain in Step (5). Bob is able to validate that the asset transfer was successful in Step (6), and the Beneficiary-VASP is able to correlate the transaction on the blockchain with Bob’s account at the Beneficiary-VASP.
There are a number of challenges related to the on-boarding of a customer already possessing a wallet. In the case that the customer wallet is regulated and previously known to another regulated VASP, then there are some practical considerations that the acquiring VASP needs to address. These include: (i) validating whether prior to on-boarding the wallet was regulated or private; (ii) validating that the keys present within the wallet corresponds to the customer’s historical transactions (confirmed on the blockchain); (iii) verifying whether a backup/migration of the wallet has occurred in the past; (iv) determining whether the customer’s assets should be moved to new keys, and if so, how the “old” keys will be treated; and so on.
The case of a customer leaving a VASP (i.e. off-boarding) also introduces a number of questions that may be relevant under the Travel Rule. The releasing VASP may need to address the following: (i) preparing evidence that the wallet was in a regulated state whilst the owner of the wallet was a customer of the VASP; (ii) whether the customer’s assets should be moved to a temporary set of keys, denoting the end of the VASP’s responsibilities for the customer under the Travel Rule; (iii) obtaining evidence from the wallet that the “old” keys (non-migrateable keys) have been erased from the wallet device, thereby rendering the keys unusable in the future by the customer; and so on.
Virtual asset insurance providers (e.g. crypto-funds insurers) need evidence regarding the physical location of private-keys, as well as the degree of technological protection afforded to those private-keys [74, 66]. This is because a private-key is the control-point for virtual assets on a blockchain. Furthermore, a dishonest user could claim loss/theft of a private-key very soon after the user moves the asset to a new anonymous private-keys on the blockchain. As such, for an insurance provider the attestation evidence information – key-creation evidence, key-movability evidence and wallet-system composition obtainable from a wallet using a trusted hardware is crucial to its risk management assessment.
There are a number of classic protocols that permit the holder to sign a challenge message, providing the challenger with proof of possession (POP) of the private-key . However, although proof of possession is useful for general applications, most classic POP protocols does not permit the key-holder to provide proof that there is only one copy of private-key and that it resides in a given trusted hardware.
Returning to Figure 8, the Beneficiary-VASP is assumed to have a business relationship (i.e. purchased insurance) with the Virtual Asset Insurance Provider (Step (a)). At any time, the Insurance Provider must have the ability to directly query the beneficiary’s wallet (Step (b)) in order to obtain attestation evidence regarding the wallet (Step (c)).
VASPs face a data problem – they need truthful information regarding subjects, such as originators, beneficiaries and other VASPs involved in a virtual asset transfer – as required by the FATF Recommendations 15 and the Travel Rule.
The VASP information sharing network is a core component of the trust infrastructures needed if blockchain systems and virtual assets are to be the foundation of the future global digital economy. VASPs need to view this information sharing network as a foundational building block for other infrastructures to be developed.
VASPs also require a trusted identity infrastructure that allow VASPs to authenticate each other and to rapidly ascertain the business legal status of other VASPs. The use of extended-validation digital certificates offers a promising solution to this problem, based on well understood and widely deployed public key certificates management technologies.
Finally, other trust infrastructures will be needed in order to address use-cases related to customer wallets and device attestations from wallets. In particular, VASPs may need evidence that the customer’s private-key truly resides within the wallet device. This provides a means for VASPs to prove that they are not the legal operator of the customer’s private-public keys.
FATF, “International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation,” Financial Action Task Force (FATF), FATF Revision of Recommendation 15, October 2018, available at: http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html.
Financial Crimes Enforcement Network (FinCEN) - Department of the Treasury, “Customer Due Diligence Requirements for Financial Institutions (31 CFR Parts 1010, 1020, 1023, 1024, and 1026; RIN 1506AB25),” Federal Register, vol. 79, no. 149, August 2014, available at: https://www.fincen.gov/sites/default/files/shared/CDD-NPRM-Final.pdf.
FinCEN, “Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies,” Financial Crimes Enforcement Network (FinCEN), FinCEN Guidance, May 2019. [Online]. Available: https://www.fincen.gov/sites/default/ files/2019-05/FinCEN\%20CVC\%20Guidance\%20FINAL.pdf
World Economic Forum, “Personal Data: The Emergence of a New Asset Class,” 2011, http://www.weforum.org/reports/ personal-data-emergence-new-asset-class.
——, “Rethinking Personal Data: A New Lens for Strengthening Trust,” May 2014, http://reports.weforum.org/rethinking-personal-data.
R. Abelson and M. Goldstein, “Millions of Anthem customers targeted in cyberattack,” New York Times, February 2015. [Online]. Available: https://www.nytimes.com/2015/02/05/ business/hackers-breached-data-of-millions-insurer-says.html
T. S. Bernard, T. Hsu, N. Perlroth, and R. Lieber, “Equifax says cyberattack may have affected 143 million in the U.S.” New York Times, September 2017. [Online]. Available: https://www.nytimes.com/2017/09/07/business/equifax-cyberattack.html
European Commission, “Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation),” Official Journal of the European Union, vol. L119, pp. 1–88, 2016.
California State Legislature, “California Consumer Privacy Act (CCPA) - AB 375,” California Civil Code – Section 1798.100, September 2018.
C. F. Kerry, “A federal privacy law could do better than California’s,” Brookings Institution, Report - Center for Technology Innovation, April 2019, https://www.brookings.edu/blog/techtank/2019/04/29/a-federal-privacy-law-could-do-better-than-californias/.
FATF, “Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers,” Financial Action Task Force (FATF), FATF Guidance, June 2019, available at: www.fatf-gafi.org/publications/fatfrecommendations/documents/Guidance-RBA-virtual-assets.html.
T. Hardjono, “Compliant Solutions for VASPs,” May 2019, presentation to the FATF Private Sector Consultative Forum (PSCF) 2019, Vienna (6 May 2019).
T. Hardjono, A. Lipton, and A. Pentland, “Towards a Public Key Management Framework for Virtual Assets and Virtual Asset Service Providers,” 2020, Journal of FinTech (to appear) – Available at https://arxiv.org/pdf/1909.08607.
S. Goldwasser, S. Micali, and C. Rackoff, “The Knowledge Complexity of Interactive Proof Systems,” SIAM J. Comput., vol. 18, pp. 186–208, April 1988. [Online]. Available: https://doi.org/10.1137/0218012
FATF, “12-Month Review of Revised FATF Standards on Virtual Assets and Virtual Asset Service Provider,” Financial Action Task Force (FATF), FATF Report, July 2020. [Online]. Available: http://www.fatf-gafi.org/publications/fatfrecommendations/documents/ 12-month-review-virtual-assets-vasps.html
S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998, IETF Standard RFC2401. [Online]. Available: http://tools.ietf.org/rfc/rfc2401.txt
D. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” August 2018, IETF Standard RFC8446. [Online]. Available: https://tools.ietf.org/html/rfc8446
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 public key infrastructure certificate and certificate revocation list (crl) profile,” May 2008, RFC5280. [Online]. Available: http://tools.ietf.org/rfc/rfc5280.txt
ISO, “Information Technology – Open Systems Interconnection – The Directory – Part 8: Public-key and Attribute Certificate Frameworks,” International Organization for Standardization, ISO/IEC 9594-8:2017, February 2017.
D. Jevans, T. Hardjono, J. Vink, F. Steegmans, J. Jefferies, and A. Malhotra, “Travel Rule Information Sharing Architecture for Virtual Asset Service Providers,” TRISA, Version 7, June 2020. [Online]. Available: https://trisa.io/wp-content/uploads/2020/06/ TRISAEnablingFATFTravelRuleWhitePaperV7.pdf
D. Riegelnig, “OpenVASP: An Open Protocol to Implement FATF’s Travel Rule for Virtual Assets,” November 2019. [Online]. Available: https://www.openvasp.org/wp-content/uploads/ 2019/11/OpenVasp\ Whitepaper.pdf
InterVASP, “InterVASP Messaging Standards IVMS101,” Joint Working Group on interVASP Messaging Standards, interVASP data model standard – Issue 1 – FINAL, May 2020.
D. Clark, “The Design Philosophy of the DARPA Internet Protocols,” ACM Computer Communication Review – Proc SIGCOMM 88, vol. 18, no. 4, pp. 106–114, August 1988.
J. Saltzer, D. Reed, and D. Clark, “End-to-End Arguments in System Design,” ACM Transactions on Computer Systems, vol. 2, no. 4, pp. 277–288, November 1984.
D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain Technology Overview,” National Institute of Standards and Technology Internal Report 8202, October 2018, https://doi.org/10.6028/NIST.IR.8202.
OASIS, “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005, available on http://docs.oasisopen.org/security/ saml/v2.0/ saml-core-2.0-os.pdf.
S. Farrell, R. Housley, and S. Turner, “An internet attribute certificate profile for authorization,” January 2010, RFC5755. [Online]. Available: http://tools.ietf.org/rfc/rfc5755.txt
GLEIF, “LEI in KYC: A New Future for Legal Entity Identification,” Global Legal Entity Identifier Foundation (GLEIF), GLEIF Research Report A New Future for Legal Entity Identification, May 2018. [Online]. Available: https://www.gleif.org/en/lei-solutions/ lei-in-kyc-a-new-future-for-legal-entity-identification
J. Newton, M. David, A. Voisine, and J. MacWhyte, “BIP75: Out of Band Address Exchange using Payment Protocol Encryption,” July 2019, Bitcoin Improvement Proposal (BIP) 75. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki
N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, “OpenID Connect Core 1.0,” OpenID Foundation, Technical Specification v1.0 – Errata Set 1, November 2014, http://openid.net/specs/openid-connect-core-1 0.html.
D. R. Kuhn, V. C. Hu, W. T. Polk, and S.-J. Chang, “Introduction to Public Key Technology and the Federal PKI Infrastructure,” National Institute of Standards and Technology, NIST Special Publication 800-32, February 2001, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-32.pdf.
E. Barker, “Recommendation for Key management (Part 1),” National Institute of Standards and Technology, NIST Special Publication SP 800-57, Part 1, Rev 4, January 2016, http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4.
National Institute of Science and Technology, “Electronic Authentication Guideline,” NIST Draft Special Publication 800-63-1, December 2008, available on http://csrc.nist.gov/publications/PubsDrafts.html,.
R. Housley, W. Ford, W. Polk, and D. Solo, “Internet X.509 public key infrastructure certificate and crl profile,” January 1999, RFC2459. [Online]. Available: http://tools.ietf.org/rfc/rfc2459. txt
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008, IETF Standard RFC5280. [Online]. Available: http://tools.ietf.org/rfc/rfc5280.txt
CAB-Forum, “Guidelines For The Issuance And Management of Extended Validation Certificates,” CA Browser Forum, Specification Version 1.7.2, March 2020.
NACHA, “Operating Rules and Guidelines,” National Automated Clearing House Association (NACHA), Specification, 2019, https://www.nacha.org.
E. Makaay, T. Smedinghoff, and D. Thibeau, “OpenID Exchange: Trust Frameworks for Identity Systems,” June 2017. [Online]. Available: http://www.openidentityexchange.org
Apple Inc., “Apple Public CA Certification Practice Statement,” Apple Inc., Certificate Practices Statement, June 2019, https://images.apple.com/certificateauthority/pdf/Apple Public CA CPS v4.2.pdf.
CableLabs, “Cablelabs New PKI Certificate Policy Version 2.1,” Cable Laboratories, Technical Specifications, January 2019, https://www.cablelabs.com/resources/digital-certificate-issuance-service.
T. Hardjono and A. Pentland, “Core Identities for Future Transaction Systems,” in Trusted Data - A New Framework for Identity and Data Sharing, T. Hardjono, A. Pentland, and D. Shrier, Eds. MIT Press, 2019, pp. 41–81.
T. Hardjono, “Federated Authorization over Access to Personal Data for Decentralized Identity Management,” IEEE Communications Standards Magazine – The Dawn of the Internet Identity Layer and the Role of Decentralized Identity, vol. 3, no. 4, December 2019. [Online]. Available: https://doi.org/10.1109/MCOMSTD.001.1900019
A. Malhotra, A. King, D. Schwartz, and M. Zochowski, “PayID Protocol,” PayID.org, Technical Whitepaper v1.0, June 2020. [Online]. Available: https://payid.org/whitepaper.pdf
M. Lizar and D. Turner, “Consent Receipt Specification Version 1.0,” March 2017, https://kantarainitiative.org/confluence/display/infosharing/Home.
D. Hardt, “The OAuth 2.0 Authorization Framework,” October 2012, RFC6749. [Online]. Available: http://tools.ietf.org/rfc/rfc6749.txt
T. Hardjono, E. Maler, M. Machulak, and D. Catalano, “User-Managed Access (UMA) Profile of OAuth2.0 – Specification Version 1.0,” Kantara Initiative, Kantara Published Specification, April 2015, https://docs.kantarainitiative.org/uma/rec-uma-core.html.
E. Maler, M. Machulak, and J. Richer, “User-Managed Access (UMA) 2.0,” Kantara Initiative, Kantara Published Specification, January 2017, https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html.
EEA, “Off-Chain Trusted Compute Specification,” Enterprise Ethereum Alliance, Technical Specification v1.1, March 2020. [Online]. Available: https://entethalliance.github.io/ trusted-computing/spec.html
Protocol Labs, “Inter Planetary File System (IPFS),” 2019, available at https://docs.ipfs.io, Accessed 23 September 2019.
D. Reed and M. Sporny, “Decentralized Identifiers (DIDs) v0.11,” W3C, Draft Community Group Report 09 July 2018, July 2018, https://w3c-ccg.github.io/did-spec/.
ISO, “Digital Object Identifier System – Information and Documentation,” International Organization for Standardization, ISO 26324:2012, June 2012, available at: http://www.iso.org/iso/catalogue detail?csnumber=43506.
S. Sun, L. Lannom, and B. Boesch, “Handle System Overview,” November 2003, RFC3650. [Online]. Available: http://tools.ietf.org/rfc/rfc3650.txt
T. Hardjono and E. Maler, “Blockchain and Smart Contracts Report,” Kantara Initiative, Report, June 2017, https://kantarainitiative.org/confluence/display/BSC/Home.
TRISA, “Travel Rule Information Sharing Architecture for Virtual Asset Service Providers (TRISA) – Version 5,” December 2019. [Online]. Available: https://trisacrypto.github.io/ white-papers/white-paper-trisa-v5.pdf
A. Pentland, Social Physics: How Social Networks Can Make Us Smarter. Penguin Books, 2015.
——, “Saving Big Data from Itself,” Scientific American, pp. 65–68, August 2014.
T. Hardjono and A. Pentland, “Open Algorithms for Identity Federation,” in Proceedings of the 2018 Future of Information and Communication Conference (FICC), Vol. 2, K. Arai, S. Kapoor, and R. Bhatia, Eds. Springer-Verlag, 2018, pp. 24–43.
OPAL Project, “OPAL: Status and Plans 2018-19,” OPAL Project, Status Report, May 2018. [Online]. Available: https://www.opalproject.org/general-overview
T. Hardjono and A. Pentland, “MIT Open Algorithms,” in Trusted Data - A New Framework for Identity and Data Sharing, T. Hardjono, A. Pentland, and D. Shrier, Eds. MIT Press, 2019, pp. 83–107.
T. Cook, “You deserve privacy online. here’s how you could actually get it,” Time Magazine, January 2019. [Online]. Available: https://time.com/collection-post/5502591/ tim-cook-data-privacy/
T. Hardjono and J. Seberry, “Strongboxes for Electronic Commerce,” in Proceedings of the Second USENIX Workshop on Electronic Commerce. Berkeley, CA, USA: USENIX Association, 1996.
Y. A. de Montjoye, E. Shmueli, S. Wang, and A. Pentland, “openPDS: Protecting the Privacy of Metadata through SafeAnswers,” PLoS ONE 9(7), pp. 13–18, July 2014, https://doi.org/10.1371/journal.pone.0098790.
Trusted Computing Group, “TPM Main – Specification Version 1.2,” Trusted Computing Group, TCG Published Specification, October 2003, available at http://www.trustedcomputinggroup.org/ resources/ tpm main specification.
O. Kharif, B. Louis, J. Edde, and K. Chiglinsky, “Interest in Crypto Insurance Grows, Despite High Premiums, Broad Exclusions,” Insurance Journal, July 2018. [Online]. Available: https://www.insurancejournal.com/news/national/2018/07/23/495680.htm
FINMA, “FINMA Guidance: Payments on the blockchain,” Swiss Financial Market Supervisory Authority (FINMA), FINMA Guidance Report, August 2019. [Online]. Available: https://www.finma.ch/en/∼/media/finma/dokumente/dokumentencenter/myfinma/ 4dokumentation/finma-aufsichtsmitteilungen/20190826-finma-aufsichtsmitteilung-02-2019. pdf
——, “FINMA Anti-Money Laundering Ordinance (AMLO) ,” Swiss Financial Market Supervisory Authority (FINMA), Verordnung der Eidgenssischen Finanzmarktaufsicht ber die Bekmpfung von Geldwscherei und Terrorismusfinanzierung im Finanzsektor, June 2015. [Online]. Available: https://www.admin.ch/opc/de/classified-compilation/20143112/index.html
Trusted Computing Group, “TCG Glossary,” Trusted Computing Group, TCG Published Specification – Version 1.1 Revision 1.0, May 2017. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf
T. Hardjono and N. Smith, “TCG Core Integrity Schema,” Trusted Computing Group, TCG Specification – Version 1.0.1 Revision 1.0, November 2006. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/ IWG-Core-Integrity\ Schema\ Specification\ v1.pdf
N. Smith (ed), “TCG Attestation Framework,” Trusted Computing Group, TCG Draft Specification – Version 1.0, February 2020.
T. Hardjono, A. Lipton, and A. Pentland, “Wallet Attestations for Virtual Asset Service Providers and Crypto-Assets Insurance,” June 2020. [Online]. Available: https://arxiv.org/pdf/2005.14689.pdf
T. Hardjono and G. Kazmierczak, “Overview of the TPM Key Management Standard,” 2008, available on http://www.trustedcomputinggroup.org/ files/ resource files/.
A. John, “Cryptocurrency industry faces insurance hurdle to mainstream ambitions,” Reuters, December 2018. [Online]. Available: https://www.reuters.com/article/us-crypto-currency-insurance/ cryptocurrency-industry-faces-insurance-hurdle-to-mainstream-ambitions-idUSKCN1OJ0BU
W. Simpson, “PPP Challenge Handshake Authentication Protocol (CHAP),” August 1996, IETF Standard RFC1994. [Online]. Available: https://tools.ietf.org/html/rfc1994