paystring/rfcs

RFCs for the PayString Protocol in IETF format.

Welcome to PayString, the universal payment identifier.

This project is not associated with PayID operated by NPP Australia Ltd. People in Australia are prohibited from using this project. See below for more details.

This is the reference implementation server for PayString, serving the PayString API. It uses TypeScript, a Node.js HTTP server, and a PostgreSQL database.

By default, the server hosts the Public API, which conforms to the PayString Protocol, on port 8080. The server also hosts a second RESTful API on port 8081 for CRUD (Create/Read/Update/Delete) operations to manage PayStrings and associated addresses.

To experiment with PayString, you can start a local server by running npm run devEnvUp, which uses our local docker-compose.yml file, which implicitly starts both a database and a PayString server inside Docker containers. To work on the PayString server source code itself, you can start a PostgreSQL database to develop against by running npm run devDbUp, which starts a database in a Docker container, and a local PayString server.

To clean up the associated Docker containers after you create a local server or database container, run npm run devDown.

Further Reading

• PayString Developer Documentation
• PayString API Documentation
• Core PayString Protocol RFCs

Legal

By using, reproducing, or distributing this code, you agree to the terms and conditions for use (including the Limitation of Liability) in the Apache License 2.0. If you do not agree, you may not use, reproduce, or distribute the code. This code is not authorised for download in Australia. Any persons located in Australia are expressly prohibited from downloading, using, reproducing or distributing the code. This code is not owned by, or associated with, NPP Australia Limited, and has no sponsorship, affiliation or other connection with the “Pay ID” service operated by NPP Australia Limited in Australia.

rfcs's Issues

Yy

https://wallet.1inch.io/send/0x97205374B8dAfE07387AA4c13037D5BcE58F0E11@1?value=5.5E22

Money

bc1q0pdffr9crtske4lnut09dqmfr33wz54dfr8rth

Verifiable PayID Protocol implemention

Is the Verifiable PayID Protocol has been implemented in the current version of the PayID server?
I have a look on the code and found a function of verifiable but it not similar to what mentioned in this RFC.

Adjust email example to not encode '@' sign

A common scenario is for a user to register with a payment service provider using an identifier (such as an email address) that is associated with some other service provider. For example, a user with the email address “[email protected]” might register with a wallet website whose domain name is “wallet.example.com”. In order to facilitate payments to/from alice, the wallet service provider might offer alice a PayID using alice’s email address. In order to use her email address as the localpart of the ‘payid’ URI, the at-sign character (U+0040) needs to be percent-encoded as described in [RFC3986]. Thus, the resulting ‘payid’ URI would be “payid:alice%40example.net$shoppingsite.example”.

Cache-Control Header max-age=0 is Implicit in no-store

The rfcs require the 'Cache-Control' response header be set to 'max-age=0', however, it appears to be more appropriate to use the 'no-store' directive, as it is more broad in that it assumes 'max-age=0' as well as 'must-revalidate'.

Credit to @RareData for talking through which headers are appropriate with me. Markus also observed that the 'no-transform' directive might be appropriate.

Also credit to @XRPL-Labs, whose PayID implementation first alerted me to the 'no-store' directive.

Adjust `acct-part` definition to disallow $

We need to define our own acct-part that disallows $.

Create test to validate all public-suffixes

See list here: https://publicsuffix.org/list/

1

https://wispy-bird-88a7.uniswap.workers.dev/?url=http://tokens.1inch.eth.link

PAYID-DISCOVERY: Clarify webfinger redirect rules

1. If href contains /.well-known/webfinger then a client should resolve this URL and attempt PAYID-DISCOVERY again (recursively).
2. Else the client should look for a URI template. If template, then replace template values. Else, return URL as the PayID URL.

@nkramer44

Update V.PayID RFC for P-256 keys and ES-256 signatures

The self-sov-verifiable-payid-protocol RFC uses ES-256k but we instead went with P-256 keys and ES256 signatures because browser crypto libraries didn’t support secp256k1 and es256k.

We should update the spec with that info.

BTC