diff --git a/dip-URI-proof-of-identity-seigler.md b/dip-URI-proof-of-identity-seigler.md index dd03b30..e97b83b 100644 --- a/dip-URI-proof-of-identity-seigler.md +++ b/dip-URI-proof-of-identity-seigler.md @@ -1,14 +1,17 @@ 
-  DIP: ?
+  BIP: ?
   Layer: Applications
   Title: URI Scheme
-  Author(s): Joshua Seigler
+  Author: Joshua Seigler 
   Status: Draft
-  Type: Standard
+  Dash-Status: Draft
+  Type: Standards Track
   Created: 2020-01-21
   License: MIT License
+This DIP extends [Dash's adaptation of BIP-0021](https://github.com/dashevo/bips/blob/master/bip-0021.mediawiki). + ## Table of Contents 1. [Abstract](#abstract) @@ -25,44 +28,32 @@ 1. [Copyright](#copyright) ## Abstract - -This DIP augments the URI scheme for making payments to include an identity -claim and a hash that proves the claim's validity. +This DIP proposes an extension to the URI scheme for making payments. ## Motivation - -The purpose of this URI scheme is to enable users to easily make payments by -simply clicking links on webpages or scanning QR Codes. +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. ## Prior Work -[BIP-0021](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki), a -URI scheme for making Bitcoin payments +Dash version of [BIP-0021](https://github.com/dashevo/bips/blob/master/bip-0021.mediawiki), a URI scheme for making Bitcoin payments +[BIP-0020](https://github.com/dashevo/bips/blob/master/bip-0020.mediawiki) ## Specification ### General rules for handling (important!) -Dash clients MUST NOT act on URIs without getting the user's authorization. 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. +Clients MUST NOT act on URIs without getting the user's authorization. +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. ### Operating system integration -Graphical Dash 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. +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. ### General format -Dash URIs follow the general format for URIs as set forth in RFC 3986. The path -component consists of a dash address, and the query component provides -additional payment options. +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. -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. +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. ### ABNF grammar @@ -71,23 +62,20 @@ corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. dashurn = "dash:" dashaddress [ "?" dashparams ] dashaddress = *base58 dashparams = dashparam [ "&" dashparams ] - dashparam = [ amountparam / labelparam / messageparam / dpnparam / otherparam / reqparam ] + dashparam = [ amountparam / labelparam / messageparam / instantsendparam / dpnparam / otherparam / reqparam ] amountparam = "amount=" *digit [ "." *digit ] labelparam = "label=" *qchar messageparam = "message=" *qchar + instantsendparam = "IS=" *bool dpnparam = "dpn=" *qchar "," *base58 otherparam = qchar *qchar [ "=" *qchar ] reqparam = "req-" qchar *qchar [ "=" *qchar ] -Here, "qchar" corresponds to valid characters of an RFC 3986 URI query -component, excluding the "=" and "&" characters, which this DIP takes as -separators. +Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this DIP takes as separators. -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. +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. -### Query keys +### Query Keys - **label**: Label for that address - **address**: dash address @@ -98,70 +86,99 @@ is case-sensitive, including the query parameter keys. ### Transfer amount -If an amount is provided, it MUST be specified in decimal dash. All amounts MUST -contain no commas and use a period (.) as the separating character to separate -whole numbers and decimal fractions. I.e. amount=50.00 or amount=50 is treated -as 50 Dash, and amount=50,000.00 is invalid. +If an amount is provided, it MUST be specified in decimal. +All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions. +I.e. amount=50.00 or amount=50 is treated as 50, and amount=50,000.00 is invalid. -Dash clients MAY display the amount in any format that is not intended to -deceive the user. They SHOULD choose a format that is foremost least confusing, -and only after that most reasonable given the amount requested. 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 or something else would be a more -logical interpretation of the amount. +Clients MAY display the amount in any format that is not intended to deceive the user. +They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. +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. ### Dash Platform Name -Dash clients MAY display the profile of a user indicated by the `dpn` field, if -the ID and signature are validated by DAPI. 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 clients MAY display the profile of a user indicated by the `dpn` field, if the ID and signature are validated by DAPI. +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. +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. +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 ### Simpler syntax -This section is non-normative and does not cover all possible syntax. Please see -the BNF grammar above for the normative syntax. +This section is non-normative and does not cover all possible syntax. +Please see the BNF grammar above for the normative syntax. -[foo] means optional, are placeholders +[foo] means optional, <bar> are placeholders - dash:
[?amount=][?label=