Change the value of currencySystem to an enum

[marcoscaceres]

Although seems pretty likely we will remove currencySystem from the spec...

For the same rationale we didn't use an URN for payment method identifiers, the currency system should be a simple enum/string value.

[adrianhopebailie]

That would defeat the purpose of having it at all.

How would someone do payments using a proprietary currency system like airline miles or loyalty points?

[marcoscaceres]

Same way we do with payment method identifiers? Use URLs.

[adrianhopebailie]

Same way we do with payment method identifiers? Use URLs.

I don't understand that proposal.

Can you give me an example PaymentCurrencyAmount?

[marcoscaceres]

// Real money
const dollars = {
    currency: "USD" ,
    value: "100000000.00",
    currencySystem: "ISO427", 
};

// Mickey Mouse Money(TM)
const mickeys = {
    currency: "MMM",
    value: "0.01",
    currencySystem: "https://disney.com/mickey/mouse/money",
};

[adrianhopebailie]

In that case why not change the type to be a URL not an enum? Why have an enum if you only have 1 value.

If no currencySystem is provided then it's assumed to be ISO4271. Or make up a URL that indicates ISO4271?

Note that in this case (as opposed to with Payment Method Identifiers) the URN for ISO4271 is a registered URN not something we're inventing for the sake of this spec.

Also note that this has been proposed before and the group didn't like URL's because that meant defining what will be found at that URL.

[marcoscaceres]

Also note that this has been proposed before and the group didn't like URL's because that meant defining what will be found at that URL.

it's exactly the same problems that PMI has. Anyway, I don't want to spend time on this, because this is already "at risk". If it survives the CR process, we can come back to it.

[adrianhopebailie]

it's exactly the same problems that PMI has.

Except that PMIs have a process to get a manifest. What would a currency system manifest look like?

[marcoscaceres]

Except that PMIs have a process to get a manifest.

They don't. It's coincidental. For example, Mozilla has currently no plans to implement Payment Manifest - but Payment Request is still usable.

What would a currency system manifest look like?

It wouldn't. It's an identifier.

[marcoscaceres]

They don't.

To be clear: there is nothing in the PMI spec that says how a manifest is fetched. That's defined by a different spec.

[adrianhopebailie]

To be clear: there is nothing in the PMI spec that says how a manifest is fetched. That's defined by a different spec.

There is still an open proposal to merge the two specs.

Mozilla has currently no plans to implement Payment Manifest - but Payment Request is still usable.

That creates some security risks that I don't think have been talked through. The role of the manifest is to allow the developer of a new payment method to limit which origins can deploy payment handlers for that method.

If you don't implement manifest then how will you provide this functionality?

[marcoscaceres]

There is still an open proposal to merge the two specs.

Bug number?

If you don't implement manifest then how will you provide this functionality?

Again, we only intend to support standardized strings (i.e., basic-card) at this point. We are not affected.

[adamroach]

@marcoscaceres --

Again, we only intend to support standardized strings (i.e., basic-card) at this point. We are not affected.

I believe you mean to qualify this with "in the short term." We certainly intend to support other payment methods in the future, and we'll have to implement any associated security mechanisms at that time.

[marcoscaceres]

Will reopen this if we need to after CR.