Clients can retrieve ProtocolMessages or EncryptedProtocolMessage awaiting them through the HTTP endpoint.
A HTTP GET request on a TLS-protected HTTP address MUST set the Accept header to the requested content type (multipart/mixed). The X-Identity header MUST be set to the hex-encoded DER-formatted public key of the requestor. The X-Signature header MUST be set to the hex-encoded DER-encoded signature (described below). The Date header MUST be set according to RFC-2616 14.18.
The signature field identifies the client is controlled by the public key provided in the X-Identity header. The signature is computed as such:
PublicKey is the public key used in the X-Identity header
Date is the UTF-8 encoded value of the Date header
URI is the URI is the UTF-8 encoded value of the full path of the HTTP endpoint's URL, excluding any trailing slashes. For example, the URL
https://example.com/paymentprococol/?v=12would become simply/paymentprococol
Signature = HexEncode(Sign(DoubleSHA256(Concat(Date, URI)), PublicKey))
The service SHOULD support basic pagination via the ts parameter. The ts parameter is an UTC UNIX timestamp in milliseconds which indicates the time by which older messages should be excluded from the response. Messages uploaded on exactly the same time as the ts should be included in the same response.
The server MUST respond with a 401 Not Authorized in the case the X-Signature header can not be validated against the request.
The service MUST respond with a 204 No Content if the client identified by X-Identity has no ProtocolMessage or EncryptedProtocolMessage(s) waiting for them.
The service MUST respond with a 200 OK if the client identified by X-Identity has one-or-more ProtocolMessage or EncryptedProtocolMessages awaiting retrieval. The Content-Type header MUST be set to multipart/mixed. Each multipart message in the response body MUST contain a Content-Type header that MUST be either application/bitcoin-paymentprotocol-message or application/bitcoin-encrypted-paymentprotocol-message as defined in RFC-1341 7.2.1
Messages MUST be ordered by chronological order of the date received with the newest at the end of the response.
The service MUST include a Date header in the response which allows clients the ability to paginate. The service MAY include a Date header along with each multipart message that indicates the time the original message was received.
The service may return messages that were returned in a previous response, so it is the client's responsibility to perform de-duplication.
Clients can remove messages from the service if they are either the recipient or the sender. This service call is authenticated in the same way the GET HTTP request is, using the X-Identity and X-Signature headers.
A HTTP DELETE on the TLS-protected HTTP address MUST include the query parameter id which indicates which EncryptedProtocolMessage's to remove. The Date, X-Identity, X-Signature headers must be set according to the signing in the HTTP GET method above. The request MAY include multiple id query parameters.
The service MUST respond with a 401 Not Authorized if the X-Signature header can not be validated.
The service MUST respond with a 204 No Content if the service did not encounter an error while processing the request. The service is not required to reveal the the requestor whether messages were removed.
Notes:
-
Add a row to the OPTIONS table for GET with MIME type
multipart/mixedand HTTP Response Content with multipart messages consisting of either ProtocolMessage or EncryptedProtocolMessage -
Change "BIP75 InvoiceRequest Submission Endpoint" to "BIP75 Message Passing Endpoint":
BIP75 Message Passing Endpoint
A bitcoin wallet developer would like to use BIP75 to pass messages between wallets. The service allows the developer to discover if the receiving wallet (via the address endpoint) supports BIP75. Additionally, the service provides the URI where BIP75 messages may be submitted and retrieved.
-
Amend "Handling BIP75 messages" to allow a 409 Conflict on submission of a duplicate message