The excellent Keybase.io service provides a means to make cryptographic claims to prove ownership of certain types of information. e.g. DNS, Twitter, etc. These proofs are independently verified by each client by retrieving a proof statement from each service in a service dependant manner.
However Keybase does not provide a way to make arbitrary claims for services, accounts, keys, etc. that are not officially supported. The ability to make such arbitrary claims, perhaps in the form of unverified key:value pairs which are valuable even if only able to be linked to a keybase account, and not independently verifiable.
Examples of this might include:
- Cryptocurrency Public Key Addresses
- Signing/Encryption Public Keys
- Unsupported service usernames (e.g. Telegram)
Until Keybase deems this capability useful something similar can be accomplished by utilizing:
- Keybase document filesystem
- Keybase Cryptographic Signatures
This is a proposal for a simple standard to publish such data and allow independat verification of the signed statements using the Keybase CLI or GUI applications.
This assumes you have installed the Keybase desktop application and have logged in and enabled the Keybase File System.
Keybase > Files > public > [USERNAME]
In your [USERNAME] folder create a sub-folder called .well-known
In your .well-known folder create a sub-folder called claims
You should end up with is a folder structure like:
Files
public
USERNAME
.well-known
claims
On macOS:
Note: The quotes are needed due to the somewhat unfriendly path.
On my system the LOCAL-USERNAME is the name of my local macOS account and is wrapped in parenthesis. The KB-USERNAME is my Keybase account name.
This is your public filesystem directory and anything in it is published by Keybase.
cd "/Volumes/Keybase (LOCAL-USERNAME)/public/KB-USERNAME"
mkdir -p
For example:
cd "/Volumes/Keybase (glenn)/public/grempe"
Make the claims dir:
mkdir -p .well-known/claims
From within your claims directory you can now create any claim. The form of these claims can vary based on your preference or the expectations of a service. A suggested form is:
A simple text file with the .txt extension where the name is a service name.
e.g. telegram.txt