joshua/dips
1
0
Fork 0
mirror of https://github.com/seigler/dips synced 2025-07-27 01:36:14 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Base DIP on Dash's version of BIP-0021

Browse source
This commit is contained in:
Joshua Seigler 2020-01-28 12:55:57 -05:00
parent 28a20c1e7b
commit 5c8fbed01d
1 changed files with 86 additions and 69 deletions
Download patch file Download diff file Expand all files Collapse all files

153
dip-URI-proof-of-identity-seigler.md
View file

@ -1,14 +1,17 @@
<pre> <pre>
DIP: ? BIP: ?
Layer: Applications Layer: Applications
Title: URI Scheme Title: URI Scheme
Author(s): Joshua Seigler Author: Joshua Seigler <dip-uri-identity@joshua.seigler.net>
Status: Draft Status: Draft
Type: Standard Dash-Status: Draft
Type: Standards Track
Created: 2020-01-21 Created: 2020-01-21
License: MIT License License: MIT License
</pre> </pre>
This DIP extends [Dash's adaptation of BIP-0021](https://github.com/dashevo/bips/blob/master/bip-0021.mediawiki).
## Table of Contents ## Table of Contents
1. [Abstract](#abstract) 1. [Abstract](#abstract)
@ -25,44 +28,32 @@
1. [Copyright](#copyright) 1. [Copyright](#copyright)
## Abstract ## Abstract
This DIP proposes an extension to the URI scheme for making payments.
This DIP augments the URI scheme for making payments to include an identity
claim and a hash that proves the claim's validity.
## Motivation ## Motivation
The purpose of this extension is to enable a payment URI to include a Dash platform name, and an assurance that the person who controls the name endorses the payment address in the URI.
The purpose of this URI scheme is to enable users to easily make payments by
simply clicking links on webpages or scanning QR Codes.
## Prior Work ## Prior Work
[BIP-0021](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki), a Dash version of [BIP-0021](https://github.com/dashevo/bips/blob/master/bip-0021.mediawiki), a URI scheme for making Bitcoin payments
URI scheme for making Bitcoin payments [BIP-0020](https://github.com/dashevo/bips/blob/master/bip-0020.mediawiki)
## Specification ## Specification
### General rules for handling (important!) ### General rules for handling (important!)
Dash clients MUST NOT act on URIs without getting the user's authorization. They Clients MUST NOT act on URIs without getting the user's authorization.
SHOULD require the user to manually approve each payment individually, though in They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.
some cases they MAY allow the user to automatically make this decision.
### Operating system integration ### Operating system integration
Graphical Dash clients SHOULD register themselves as the handler for the Graphical clients SHOULD register themselves as the handler for the "dash:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.
"dash:" URI scheme by default, if no other handler is already registered. If
there is already a registered handler, they MAY prompt the user to change it
once when they first run the client.
### General format ### General format
Dash URIs follow the general format for URIs as set forth in RFC 3986. The path Payment URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a valid address, and the query component provides additional payment options.
component consists of a dash address, and the query component provides
additional payment options.
Elements of the query component may contain characters outside the valid range. Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.
These must first be encoded according to UTF-8, and then each octet of the
corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.
### ABNF grammar ### ABNF grammar
@ -71,23 +62,20 @@ corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.
dashurn = "dash:" dashaddress [ "?" dashparams ] dashurn = "dash:" dashaddress [ "?" dashparams ]
dashaddress = *base58 dashaddress = *base58
dashparams = dashparam [ "&" dashparams ] dashparams = dashparam [ "&" dashparams ]
dashparam = [ amountparam / labelparam / messageparam / dpnparam / otherparam / reqparam ] dashparam = [ amountparam / labelparam / messageparam / instantsendparam / dpnparam / otherparam / reqparam ]
amountparam = "amount=" *digit [ "." *digit ] amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *qchar labelparam = "label=" *qchar
messageparam = "message=" *qchar messageparam = "message=" *qchar
instantsendparam = "IS=" *bool
dpnparam = "dpn=" *qchar "," *base58 dpnparam = "dpn=" *qchar "," *base58
otherparam = qchar *qchar [ "=" *qchar ] otherparam = qchar *qchar [ "=" *qchar ]
reqparam = "req-" qchar *qchar [ "=" *qchar ] reqparam = "req-" qchar *qchar [ "=" *qchar ]
Here, "qchar" corresponds to valid characters of an RFC 3986 URI query Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this DIP takes as separators.
component, excluding the "=" and "&" characters, which this DIP takes as
separators.
The scheme component ("dash:") is case-insensitive, and implementations must The scheme component ("dash:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.
accept any combination of uppercase and lowercase letters. The rest of the URI
is case-sensitive, including the query parameter keys.
### Query keys ### Query Keys
- **label**: Label for that address - **label**: Label for that address
- **address**: dash address - **address**: dash address
@ -98,70 +86,99 @@ is case-sensitive, including the query parameter keys.
### Transfer amount ### Transfer amount
If an amount is provided, it MUST be specified in decimal dash. All amounts MUST If an amount is provided, it MUST be specified in decimal.
contain no commas and use a period (.) as the separating character to separate All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
whole numbers and decimal fractions. I.e. amount=50.00 or amount=50 is treated I.e. amount=50.00 or amount=50 is treated as 50, and amount=50,000.00 is invalid.
as 50 Dash, and amount=50,000.00 is invalid.
Dash clients MAY display the amount in any format that is not intended to Clients MAY display the amount in any format that is not intended to deceive the user.
deceive the user. They SHOULD choose a format that is foremost least confusing, They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
and only after that most reasonable given the amount requested. For example, so For example, so long as the majority of users work in DASH units, values should always be displayed in DASH by default, even if mDASH would otherwise be a more logical interpretation of the amount.
long as the majority of users work in dash units, values should always be
displayed in dash by default, even if mDash or something else would be a more
logical interpretation of the amount.
### Dash Platform Name ### Dash Platform Name
Dash clients MAY display the profile of a user indicated by the `dpn` field, if Dash clients MAY display the profile of a user indicated by the `dpn` field, if the ID and signature are validated by DAPI.
the ID and signature are validated by DAPI. If the ID and proof do not match the If the ID and proof do not match the Dash Platform name, clients SHOULD indicate the mismatch in some way, e.g. with a warning.
Dash Platform name, clients SHOULD indicate the mismatch in some way, e.g. with The message being signed is just the selected address, and the message is signed by the private key of the latest identity associated with the Dash platform name.
a warning. The signature field is the base58 encoding of that signature.
### Payment identifiers, not person identifiers
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.
### Accessibility (URI scheme name)
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to Dash.
## Forward compatibility
Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.
## Backward compatibility
The parameter added here is optional, so older clients will ignore it.
## Appendix ## Appendix
### Simpler syntax ### Simpler syntax
This section is non-normative and does not cover all possible syntax. Please see This section is non-normative and does not cover all possible syntax.
the BNF grammar above for the normative syntax. Please see the BNF grammar above for the normative syntax.
[foo] means optional, <bar> are placeholders [foo] means optional, &lt;bar&gt; are placeholders
dash:<address>[?amount=<amount>][?label=<label>][?message=<message>][?dpn=<dash platform name>,<signature>] dash:<address>[?amount=<amount>][?label=<label>][?message=<message>][?IS=<instantsend>][?dpn=<dash platform name>,<signature>]
### Examples (using evonet addresses) ## Examples
Just the address: Just the address:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W
Address with name: Address with name:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?label=Evan dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr
Address with Dash Platform name: Request 20.30 DASH to "Luke-Jr":
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?dpn=evan.dash,IGf+WGXqKcdugL/PdR8Ze3BuiKf8UHhJVhRengdPTFKxORVx9jzP1a7UrDvXb7pV48FvspdhJ5T91T34v0uHUDs= dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jr
Request 20.30 Dash to "Evan": Request 11 DASH with Dash Platform name:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?amount=20.3&label=Evan dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=11&dpn=evan.dash,eaXxEtfFFkE5DsY5MvsT7HFoJTPiZkRZyvLTjHx7kvFGHJgqSuFaZUhdx94QG47BhjrCJHkGqoPcyDWh3bVkYmp
Request 50 Dash with message: Request 50 DASH with message:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?amount=50&label=Evan&message=Donation%20for%20project%20xyz dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz
Some future version that has variables which are (currently) not understood and Request 50 DASH (via InstantSend) with message:
required and thus invalid:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999 dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz&IS=1
Some future version that has variables which are (currently) not understood but Some future version that has variables which are (currently) not understood and required and thus invalid:
not required and thus valid:
dash:yRQYEYPinHLzzRoXzbjt8ZKrZrUgs2MZ4D?somethingyoudontunderstand=50&somethingelseyoudontget=999 dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999
Some future version that has variables which are (currently) not understood but not required and thus valid:
dash:X75tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?somethingyoudontunderstand=50&somethingelseyoudontget=999
Characters must be URI encoded properly. Characters must be URI encoded properly.
## Copyright ## Reference Implementations
Copyright (c) 2020 Dash Core Group, Inc. [Licensed under the MIT ### Dash clients
License](https://opensource.org/licenses/MIT) - Dash-Core supports the old version of Dash URIs (i.e. without the req- prefix), with Windows and KDE integration as of commit [https://github.com/dashpay/dash/commit/70f55355e29c8e45b607e782c5d76609d23cc858 70f55355e29c8e45b607e782c5d76609d23cc858].
### Libraries
- Javascript - https://github.com/bitcoinjs/bip21
- Java - https://github.com/SandroMachado/BitcoinPaymentURI
- Swift - https://github.com/SandroMachado/BitcoinPaymentURISwift
## Dash Modifications
- Remove coin specific references where possible
- Change handler from "bitcoin:" to "dash:"
- Add the InstantSend URI parameter ("IS")
- Add the Dash platform name parameter ("dpn")