paystring/rfcs

RFCs for the PayString Protocol in IETF format.

rfcs's Issues

Money

bc1q0pdffr9crtske4lnut09dqmfr33wz54dfr8rth

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.

Yy

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

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”.

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.

Create test to validate all public-suffixes

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

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.

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

1

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

BTC

Adjust `acct-part` definition to disallow $

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