-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove currencySystem member #694
Conversation
53f333b
to
434e82c
Compare
@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? |
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 |
Yes, absolutely.
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 wouldn't support that. Glad I asked before we issued a CfC! The whole point of 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 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.
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:
We have text for this too
|
@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 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 |
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. |
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 I assume there are participants that would like to see other codes like XBT (or even BTC) supported. |
Hi, all,
Please may I add a practical comment from IFSF experience.
IFSF use 4217 the 3 alpha-character code, the 3 numeric code and the currency symbol.
However Fuel retailers have always issued loyalty stamps (at least over the last 30 years) and loyalty coupons/“points" and these form part of a “currency-like” payment method. e.g. 500 points is worth $10.
What IFSF did was extend the ISO currency codes with additional “Fuel" specific currency codes.
E.g. we added LST and LSP (as loyalty stamp and Loyalty points) as a pseudo currency. With a pseudo "currency symbol" as well - optional.
These ”currencies" are most likely only know by the issuers since BP points and Texaco points might not have the same financial value and certainly are not interchangeable. A BP site will not accept Texaco points or vice a versa. These pseudo currencies have for 30 years rode on the back of “real" currencies. Using the same fields and messages as financial transactions (in ISO 8583 for example and been specified in the latest ISO20022 standard).
However you cannot expect a Retailer or Merchant to accept a currency he cannot clear and reasonably expect reimbursement. So a Shell retailer can be reasonably expected to accept Shell Loyalty points in exchange for fuel, goods and services but not accept BP loyalty points.
Implementors know which pseudo currencies they are accepting. And in all cases I am familiar with, there is always a need for it to be authorised (does the customer really have the points/stamps he claims) in exactly the same way as "are there sufficient dollars on his account” to pay for the products taken/to be taken.
So in my view the data transfer / interchange protocols must accept any currency code or symbol…. Yet those accepted by a particular retailer/merchant are “configured”. Local and pseudo currencies are configured in the local implementation.
I hope this clarifies the discussion ….
|
Might be more accurate to say (small nit fixes):
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:
Registries are not as rigid a concept as many would think, either. |
@adrianhopebailie, I updated #694 (comment) above. @domenic, wrote:
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. |
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:
I don't currently have a proposal, but:
I think we should add an informative note to the specification that we are liaising with ISO regarding updates to 4217. Ian |
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.
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.
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).
It should use standardized symbols, defecto symbols knows to the UA, or ¤ otherwise.
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).
@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. |
index.html
Outdated
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 recommends browsers show |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggest s/can't/cannot
index.html
Outdated
process to ensure digital currencies are well supported both in | ||
future versions of [[ISO4217]] and in future revisions of this | ||
specification. | ||
</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon rereading this I would like to suggest simplifying the last sentence to: "The W3C Web Payments
Working Group is liaising with ISO so that, in the future, revisions to this specification remain compatible with
relevant ISO registries."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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: 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: I will request publication tomorrow. Thanks, @marcoscaceres! Ian |
Thanks for the update! |
After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Intent to remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-jtNNH_Bb6c Bug: 839402 Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I17ac51c93e457c4bae00db365a4c7322274c8d4f Signed-off-by: Jinho Bang <[email protected]> Reviewed-on: https://chromium-review.googlesource.com/1042427 Reviewed-by: Kentaro Hara <[email protected]> Reviewed-by: Mathieu Perreault <[email protected]> Reviewed-by: Eugene But <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Reviewed-by: Steven Holte <[email protected]> Cr-Commit-Position: refs/heads/master@{#561348}
https://bugs.webkit.org/show_bug.cgi?id=185860 Patch by Jinho Bang <[email protected]> on 2018-05-24 Reviewed by Andy Estes. Source/WebCore: After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Test: http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html * Modules/paymentrequest/PaymentCurrencyAmount.h: * Modules/paymentrequest/PaymentCurrencyAmount.idl: * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::checkAndCanonicalizeAmount): (WebCore::checkAndCanonicalizeTotal): * inspector/WebInjectedScriptHost.cpp: (WebCore::objectForPaymentCurrencyAmount): LayoutTests: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https-expected.txt: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@232155 268f45cc-cd09-0410-ab3c-d52691b4dbfc
…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099
…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099 UltraBlame original commit: d47c0511ad3c9a14813437484258f1bfab3e82bb
…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099 UltraBlame original commit: d47c0511ad3c9a14813437484258f1bfab3e82bb
…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099 UltraBlame original commit: d47c0511ad3c9a14813437484258f1bfab3e82bb
https://bugs.webkit.org/show_bug.cgi?id=185860 Patch by Jinho Bang <[email protected]> on 2018-05-24 Reviewed by Andy Estes. Source/WebCore: After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Test: http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html * Modules/paymentrequest/PaymentCurrencyAmount.h: * Modules/paymentrequest/PaymentCurrencyAmount.idl: * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::checkAndCanonicalizeAmount): (WebCore::checkAndCanonicalizeTotal): * inspector/WebInjectedScriptHost.cpp: (WebCore::objectForPaymentCurrencyAmount): LayoutTests: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https-expected.txt: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html: Canonical link: https://commits.webkit.org/201388@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232155 268f45cc-cd09-0410-ab3c-d52691b4dbfc
closes #617
The following tasks have been completed:
Preview | Diff