Home

Awesome

OpenCAP

Inception: July 2018

Discord: https://discord.gg/FTMCBE8

<hr>

Contents

Problem

Solution

Anatomy of an Alias

API

Text Standard

Attack Vectors

Justifications

Contribute

OpenCAP Compliant Applications

OpenCAP Development Tools

<hr>

Problem

Sending cryptocurrency is not as easy as sending fiat currently. Centralized apps like Venmo, Swish, or Square Cash are more convenient and have less room for error in that they allow users to send money via usernames, emails, or phone numbers which are easy to remember and verify. Cryptocurrency addresses by nature are hard to remember, and when typed manually can easily contain errors.

Cryptocurrency addresses also change over time for a given user in some currencies (wallets use new addresses for each transaction, or users create new wallets). When posting addresses online, future payments will use the same address which defeats the purpose of the non-reuse feature. An alias relates to an address that can be updated, which solves this problem.

<hr>

Solution

OpenCAP is a protocol that defines the standard by which cryptocurrency wallets can communicate with servers to relate aliases to cryptocurrency addresses. The protocol allows for the decentralization of the alias --> address relationship. Anyone can use the protocol to build/host their own server on their own domain. Servers can be majorly centralized, or individuals can run their own servers, much like SMTP (email).

OpenCAP is adhered to by both client (wallet) software and server (address storage) sofware. Wallets must know how to properly parse an alias and perform the proper API calls. Servers must know how to handle those requests in the proper manner and send back valid data. Any given wallet and server that adhere to the OpenCAP protocol will be able to communicate cryptocurrency address information seamlessly.

OpenCAP is a simple protocol that does one thing: relate aliases to addresses. Servers can of course add more features to their servers (profile pictures, address re-use and validation, etc.) but these features are not a part of the base protocol.

<hr>

Anatomy of an Alias

{username}${domain name}

example: donate$ogdolo.com

The anatomy of an OpenCAP alias may remind you of an email address. The only difference being the seperator between username and domain. However it is very important to note that email addresses have nothing to do with OpenCAP aliases other than that they share a similar format.

The {username} section of the alias is only allowed to use:

  1. Lower-case letters
  2. Numbers
  3. The following punctuation:
    • "."
    • "-"
    • "_"
  4. And must be between 1 and 25 characters in length, inclusive

The {domain name} section of an alias may only use valid ASCII characters, which eliminates the use of some international domain names. This is intended to protect against an IDN Homograph Attack

<hr>

API

The OpenCAP protocol at the end of the day is just a REST API specification. There are two tiers to the API, "Address Query" and "Alias Management". An OpenCAP server MUST support the "Address Query" endpoints and protocol, while the Alias Management endpoints are optional.

API SpecificationServerWallet
Address QueryReturn addresses given an aliasSupport payments to aliases
Alias ManagementAllow RESTful updates to addresses and usersSupport RESTful API calls to update addresses and users

Domain Proxy

The main reason OpenCAP uses an SRV record to find the location of the host server (see Address Query) is because OpenCAP can support proxied domains. For more information on this see here.

<hr>

Text Standard

All the text data transfer in the protocol can be assumed to be valid UTF-8 encoded.

<hr>

Attack Vectors

Address Swaps

The most obvious way for a malicious party to use the alias system to steal funds would be to hack a OpenCAP server and secretly change out addresses so that their address is associated with someone else's alias.

Possible remedies:

Payment Tracking

It is fairly simple for a third party to constantly poll a given alias's endpoint and record all that alias's addresses over time. While the alias protocol isn't necessarily meant to have stringent privacy measures (the whole point of an alias is to relate a public account to an address) there are a couple things that can be done to increase privacy:

Cross-Site Scripting XSS

Like any javascript client, wallets and other client-side OpenCAP software can be vulnerable to XSS attacks. All OpenCAP software must take precautions to not allow any data returned by a potentially untrustworthy server to be injected in a script and ran.

Reference:

Wikipedia Cross-Site Scripting

DNS Poisoning and MITM attacks

Because we are using the DNS system for SRV record lookups and to make API calls, there is potential for some form of DNS attack. If not handled properly this kind of attack could result in stolen funds because a malicious user could redirect API calls to their own server with their own addresses. None of the following solutions are required by OpenCAP but are suggestions that individual software implementations can use to help mitigate attacks.

Servers

Wikipedia DNSSEC

Wallets (clients)

Individuals

<hr>

Justifications

  1. OpenCAP is a communication protocol only. Using TXT records couples the communication layer to the data store. We want developers to have the freedom to use whatever data store they choose.

  2. Certain features aren't possible using DNS lookups. One example is that an OpenCAP server has the potential to serve a new address for each incoming GET request, preserving privacy. There is no way to guarantee this using DNS records.

  3. For most web developers (especially newer web developers) it is simpler to work with a REST API than to create, update, delete, and query DNS records. This simplicity should help with adoption.

  1. We didn't want to bloat an existing blockchain with superflous data that isn't directly related to transactions and balances.

  2. OpenCAP leaves the level of centralization up to the users. Some will use third-party OpenCAP providers. Others will run their own OpenCAP servers for complete control.

  3. In many cases it isn't desirable for an alias system to be immutable. OpenCAP leaves this up to the implementation.

  4. OpenCAP can achieve much faster create/update/delete operations than data stored on a blockchain, which means an alias can be changed quickly over time if desired.

<hr>

Contribute

OpenCAP is an open-source protocol please feel free to submit change proposals via the "issues" tab on github, or by submitting a pull request.

Build software that supports the protocol! The more wallets and servers using OpenCAP, the more useful it will be. If you aren't a developer, reach out to your favorite project teams and let them know about aliases.

<hr>

OpenCAP Compliant Applications

LinkType
VolaNano wallet, Alias provider (Address Query)
NanolletNano wallet (Address Query)
Mynano.ninjaAlias provider (Address Query)
OpenCAP Server (implemented in go)Self hostable open source server
OpenCAP Server (implemented in js)Self hostable open source server

OpenCAP Development Tools

LinkType
go-opencapUseful helper functions for Go developers
opencap-jsLibrary for JS developers.