@marcoscaceres this was discussed on the call today. Chairs will send out a CfC to remove currencySystem.

It would be helpful if that could include some description of what will be supported. Specifically, can someone use PR API to accept a Bitcoin, Ethereum or XRP payment for example?

I think I understand the current implementations as being able to handle any currency that is expressed as a 3 char code but would like to confirm that this is not limited to the official ISO 4217 set?

@marcoscaceres,

After discussion with @adrianhopebailie, we propose to start the CfC after hearing your reply to his question on current implementation behavior.

Also, will the spec say anything about recovery in the case of non-standard codes?

Ian

It would be helpful if that could include some description of what will be supported. Specifically, can someone use PR API to accept a Bitcoin, Ethereum or XRP payment for example?

Yes, absolutely.

I think I understand the current implementations as being able to handle any currency that is expressed as a 3 char code but would like to confirm that this is not limited to the official ISO 4217 set?

I think for v1, we should do ISO 4217 (get us past CR). But, in parallel (like starting today!), we should spin up our own currency registry (similar to the card brands registry) - and we should use that registry to coordinate with the ISO folks. Basically, currency codes we come up with should end up in future updates to ISO 4217. According to Wikipedia, ISO is already considering some preliminary cryptocurrency codes. @ianbjacobs, do we know anyone at SIX Interbank Clearing AG we can talk to?

@marcoscaceres, I will see if I can start a conversation with SIX Interbank Clearing AG.

In the meantime, I have added to the FTF agenda the topic of a local registry.

@adrianhopebailie, should we proceed with a CfC about the removal of the feature and discussion in Singapore? Or wait until after that discussion to remove it?

Ian

I think for v1, we should do ISO 4217 (get us past CR). But, in parallel (like starting today!), we should spin up our own currency registry (similar to the card brands registry) - and we should use that registry to coordinate with the ISO folks.

I wouldn't support that. Glad I asked before we issued a CfC!

The whole point of currencySystem was to not force users to use only currencies from a registry.

Currencies are not as rigid a concept as many would think.

I can make up a currency today and have a community who are willing to trade in that currency online but I am prohibited from using PR until I get my currency on some registry and wait for browsers to add support for it?

There are currently over 1500 crypto-currencies listed at https://coinmarketcap.com/all/views/all/

There are innumerable private loyalty points schemes that will want to ultimately allow their users to pay with their points.

This is a scaling problem we can't solve using a registry and I certainly don't think W3C wants to maintain it nor do you want to have to keep your browsers up to date with it.

I propose that for CR we make no mention of ISO 4217 and stick with the reference to https://www.ecma-international.org/ecma-402/4.0/index.html#sec-iswellformedcurrencycode which appears to allow any uppercase alpha code that is exactly 3 chars long and doesn't appear to compare the value to a set of allowed values.

Anyone that wants to use non-ISO 4217 currencies just needs to find an appropriate 3 letter code. (ISO 4217 allocated the X** namespace for exactly that use case, unfortunately not everyone in the crypto-currency world adhered to that).

So, if I use the values XBT (Bitcoin), XRP, or ETH I should be able to use PR, but I would understand if the browser didn't have a nice currency symbol to show on the UI.

I would support removing currency system because not a single merchant or payment app has partnered with us to use a non-standard currency. When/if this happens, we can revisit the problem. At this time, I would prefer to solve the use cases of the people that are interested in working with us.

@adrianhopebailie, wrote:

I can make up a currency today and have a community who are willing to trade in that currency online but I am prohibited from using PR until I get my currency on some registry and wait for browsers to add support for it?

I think this is a very important discussion that we need to have. @ianbjacobs, @adrianhopebailie, something to add to the f2f agenda? The question is, how do we keep users safe from bad actors in the cryptocurrency ecosystem, while also empowering good actors?

Lately, due to high fraud, companies like Google and Facebook have moved to ban advertising of cryptocurrencies on their platforms (with Twitter possibly following suit). This is very concerning, obviously, so we are interested in ways of minimizing the risks of users being asked to pay with, or to buy, fraudulent cryptocurrencies.

I propose that for CR we make no mention of ISO 4217 and stick with the reference to https://www.ecma-international.org/ecma-402/4.0/index.html#sec-iswellformedcurrencycode which appears to allow any uppercase alpha code that is exactly 3 chars long and doesn't appear to compare the value to a set of allowed values.

That's pretty much where we end up after this PR - except descriptively references ISO4217 so a reader knows about the 3-letter format. There is no algorithmic check that the code must exist in "ISO 4217" (i.e., it's just the well-formedness check, as you point out).

@adrianhopebailie, wrote:

So, if I use the values XBT (Bitcoin), XRP, or ETH I should be able to use PR, but I would understand if the browser didn't have a nice currency symbol to show on the UI.

We have text for this too ☺️:

Where a localized currency symbol is not available, a user agent SHOULD use U+00A4 (¤) for formatting.

@marcoscaceres, I think we're on the same page I just wanted to be clear on the nuances of what we're proposing to end up with after taking out currencySystem.

Can we include the following in the CfC to give WG members a summary of the expected new behaviour:

"Implementations will support a single currency system, ISO 4217. Specifically they will expect currency codes to be well-formed 3-letter codes as defined by ECMA 6 isWellFormedCurrencyCode. Implementations will therefor allow the use of well-formed codes that are not recognized currency codes from the ISO 4217 list such as XBT, XRP etc. If the provided code is a recognized currency then implementations MAY provide additional UI hints such as appropriate symbols in the user interface."

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies. Given comments so far in this thread (e.g. @rsolomakhin's), I don't think that's clear at all.

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies.

Then that begs the question, why would they not allow these currencies? My understanding of the issue when it first came up was the desire to be able to do UI related stuff like show appropriate currency symbols. If that is not the only limitation then we should discuss these new constraints.

Let me say on the record Ripple would like to see support for XRP as a currency code and has demonstrated a number of examples over the last year of how this would be used in conjunction with the interledger payment method so there is at least one participant asking for non-ISO but well-formed.

I assume there are participants that would like to see other codes like XBT (or even BTC) supported.

Might be more accurate to say (small nit fixes):

Implementations enforce ISO ISO 4217's 3-letter codes format via ECMAScript’s “isWellFormedCurrencyCode” algorithm. Implementations will therefore allow the use of well-formed currency codes that are not part of ISO 4217 list (e.g., XBT, XRP etc.). If the provided code is a currency that the browser knows how to display, then implementation usually provide additional UI hints such as appropriate symbols in the user interface (e.g., "USD" is shown as "$", "GBP" is "£", and so on). When a code is can't be matched, we recommend browsers show a scarab "¤".

We are continuing to evolve the standard as we gain experience as to how it’s going to be used.

But it would be really helpful to this discussion to see examples of retailer’s websites that use points/alternative currencies that they themselves don’t control. A few screenshots would really help!

@adrianhopebailie said:

Currencies are not as rigid a concept as many would think.

Registries are not as rigid a concept as many would think, either.

@adrianhopebailie, I updated #694 (comment) above.

@domenic, wrote:

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies.

Agree. I've spun up mozilla/standards-positions#78 for Mozilla opinions (in the context of cryptocurrencies and in currencies in general). Some interesting feedback and questions there already.

@marcoscaceres, @adrianhopebailie, I am making progress on my outreach to the people that maintain ISO 4217. Stay tuned!

Concluded on the Mozilla side that things as currently specified are ok. The comment at #694 (comment) reflects how things work after this PR is merged - and reflects what user agents implement today.

Would like to encourage us to continue to liaise with ISO on all codes and symbols nevertheless.

@marcoscaceres,

Regarding liaison: This week I have a call with the relevant people around ISO 4217.

@ianbjacobs appreciate the update! thank you!

@marcoscaceres, @adrianhopebailie,

Here's what I learned from my conversation with our ISO 4217 colleagues:

• There will be a registry for non-fiat digital currencies (which they may call "digital tokens" so as not to clash with the definition of "currency" in ISO 4217)
• These codes most likely will not be 3-letter strings (due to name conflicts and scarcity).
• It is possible (but not known for sure) that they will be 4-letter strings.
• The time frame for the specification and registry is not known, but a guess is "1 year from now."

I don't currently have a proposal, but:

• I am hearing people want to be able to use non-4217 codes with PR API.
• I assume people want to avoid name conflicts (e.g., does BTC refer to Bitcoin or
  to a future Bhutan currency according to the 4217 naming convention?)
• This suggests some naming convention could help the browser recognize that someone has intentionally provided a non-standard code.
• If ISO is likely (but not guaranteed) to use a letter-based code system, would it be appropriate for authors that wish to specify a non-4217 code (or other future ISO registry) to use a non-letter prefix (e.g., "-")? Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"?
• Should there be consistent display guidance to browser implementations for non-standard codes? (e.g., if the merchant-provided code is -BTC, display "BTC")? Or should the browser be free to show other symbols?
• How are other errors handled (e.g., a string of 47 characters)?

I think we should add an informative note to the specification that we are liaising with ISO regarding updates to 4217.

Ian

I am hearing people want to be able to use non-4217 codes with PR API.

Limited supported today, so long as the code adheres to the ISO4217 format (with the known limitations/ambiguities you mentioned).

Once we know what the new format is going to be (length, allowed chars), we should incorporate that.

If ISO is likely (but not guaranteed) to use a letter-based code system, would it be appropriate for authors that wish to specify a non-4217 code (or other future ISO registry) to use a non-letter prefix (e.g., "-")? Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"?

We definitely don't want to go down this path. That's HTTP's "x-frame-options" etc. and vendor prefixing all over again.

If we do "-Whatever", then that's the standards.

Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"?

No. We don't do that today either. We just check the format (e.g. "YXA" is a perfectly valid currency code, which doesn't exist).

Should there be consistent display guidance to browser implementations for non-standard codes? (e.g., if the merchant-provided code is -BTC, display "BTC")? Or should the browser be free to show other symbols?

It should use standardized symbols, defecto symbols knows to the UA, or ¤ otherwise.

How are other errors handled (e.g., a string of 47 characters)?

RangeError.

Thanks everyone for the productive discussion here. I want to give a summary of where we are so far (and perhaps we should add the following to the spec as a note, as @ianbjacobs suggested).

User agents implementing Payment Request enforce ISO 4217's 3-letter codes format via ECMAScript’s “isWellFormedCurrencyCode” algorithm. When a code does not adhere to the ISO 4217 defined format, a RangeError is thrown.

Current implementations of the Payment Request API will therefore allow the use of well-formed currency codes that are not part of the official ISO 4217 list (e.g., XBT, XRP, etc.). If the provided code is a currency that the browser knows how to display, then an implementation will generally display the appropriate currency symbol in the user interface (e.g., "USD" is shown as "$", "GBP" is "£", and the non-standard "XBT" could be shown as "Ƀ"). When a code can't be matched, the specification recommend browsers show a scarab "¤".

Given the rise of digital currencies in recent years, ISO 4217's format has been found wanting. For example, does "BTC" refer to Bitcoin or to a future Bhutan currency according to the 4217 naming rules? To overcome the limitations with ISO 4217 with respect to digital currencies, ISO is in the early stages of evolving ISO 4217. At the time of publication, it remains unclear what form this evolution will take, or even the timeframe in which the work will be completed. The W3C Web Payments Working Group is liaising with ISO during this evolutionary process to ensure digital currencies are well supported both in future versions of ISO 4217 and in future revisions of the Payment Request API.

@adrianhopebailie wdty? I can send the above as PR and we can iterate.

@marcoscaceres LGTM

Do we want to encourage the use of "X" prefixed codes for currencies that are not from a particular country? i.e. Use XBT instead of BTC to improve interoperability

@marcoscaceres, proposed:

Change:

"Given the rise of digital currencies in recent years, ISO 4217's format has been found wanting. For example, does "BTC" refer to Bitcoin or to a future Bhutan currency according to the 4217 naming rules? To overcome the limitations with ISO 4217 with respect to digital currencies, ISO is in the early stages of evolving ISO 4217. "

to:

"Efforts are underway at ISO to account for digital currencies in the ISO 4217 registry or a new one. We expect this will resolve ambiguities that have crept in through the use of non-standard 3-letter codes; for example, does "BTC" refer to Bitcoin or to a future Bhutan currency?"

The rest looks fine, thank you!

Ian

This should be good to go. Will remove the WPTests once this goes in.

@marcoscaceres,

As discussed in Singapore, I'm ready to issue a call for consensus to close this pull request. However, I'd like to see whether you would accept my editorial suggestions before I send the email.

Ian

Suggestions are good. Will try to integrate them tomorrow. please start the cfc 🙂

Call for consensus underway:
https://lists.w3.org/Archives/Public/public-payments-wg/2018Apr/0020.html

Ian

Blocked until 1st of May, pending outcome of CFC.

@ianbjacobs, addressed your feedback. If looks good, please ✅.

@ianbjacobs, the CFC finishes at 10am ET today, so, now that this is merged, could you kindly send another request for publication after that?

Decision sent:
https://lists.w3.org/Archives/Public/public-payments-wg/2018May/0001.html

I will request publication tomorrow. Thanks, @marcoscaceres!

Ian

Thanks for the update!