BIP 0070 has been a a moderate success, however, IMO:
-
protocol buffers are inappropriate since ease of use and extensibility is desired over the minor gains of
efficiency in this protocol. Not too late to support JSON messages as the standard going forward
- problematic reliance on merchant-supplied https (X509) as the sole form of mechant identification. alternate schemes (dnssec/netki), pgp and possibly keybase seem like good ideas. personally, i like keybase, since there is no reliance on the existing domain-name system (you can sell with a github id, for example)
- missing an optional client supplied identification
- lack of basic subscription support
- BIP0047 payment codes are recommended instead of wallet addresses when establishing subscriptions. Or, merchants can specify replacement addresses in ACK/NACK responses. UI confirms are
required when there are no replacement addresses or payment codes used.
- Wallets must confirm and store subscriptions, and are responsible for initiating them at the specified interval.
- Intervals can
only be from a preset list: weekly, biweekly, or 1, 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause suspension until the user re-verifies.
- Wallets
may optionally ask the user whether they want to be notified and confirm every interval - or not. Wallets that do not ask
must notify before initiating each payment. Interval confirmations should begin at
least 1 day in advance of the next payment.
Proposed in general:
- JSON should be used instead of protocol buffers going forward. Easier to use, explain extend.
- "Extendible" URI-like scheme to support multi-mode
identity mechanisms on both payment and subscription requests. Support for keybase://, netki:// and others as alternates to https://.
- Support for client as well as merchant multi-mode verification
- Ideally, the identity verification URI scheme is somewhat orthogonal/independent of the payment request itself
Question:
Should this be a new BIP? I know netki's BIP75 is out there - but I think it's too specific and too reliant on the domain name system.
Maybe an identity-protocol-agnostic BIP + solid implementation of a couple major protocols without any mention of payment URI's ... just a way of sending and receiving identity verified messages in general?
I would be happy to implement plugins for identity protocols, if anyone thinks this is a good idea.
Does anyone think https:// or keybase, or PGP or netki all by themselves, is enough - or is it always better to have an extensible protocol?
- Erik Aronesty