Should well-known identifiers be used for ubiquitous payment methods

[adrianba]

This issue comes from WICG/paymentrequest#35 and was discussed at the F2F.

[adrianhopebailie]

In #149 @dret said:

the current draft defines/allows identifiers to be used in short or long forms. most experience with identifiers in the wild shows that no matter how clear equivalence rules are defined, they tend to be ignored, leading to problems with identifier recognition, and interoperability issues. unless there is a very compelling reason why non-unique identifiers should be supported, it may be better to forego the convenience of a shortcut notation, and always require identifiers in some canonical form.

[rvm4]

I think as a first effort we should forgo short from identifiers. Short form identifiers only become useful when you have a critical mass of payment apps that fundamentally support the same payment method. I believe this is unlikely to be a huge problem at the time of adoption and can be easily appended in a V2 spec.

[rvm4]

I also think that that short-form identifiers are troublesome on the response side of the flow. If there are two payment apps that say they can return credit card info, the expectations from the payee is that this info is standardized between the two apps, which in turn means we need to designate what that looks like. I think specing out what the response looks like for a "CC" payment method is going to be tricky and so should also be tackled as a V2 if needed.

[adrianhopebailie]

The group has resolved to use absolute URLs as identifers and is now awaiting a proposal for how short-form identifiers may be implemented

[rsolomakhin]

I think short-form identifiers can be relative URLs under W3C control. For example,

• visa -> https://w3c.org/payments/visa
• amex -> https://w3c.org/payments/amex
• etc

So [SHORT-FORM] is a shorthand for https://w3c.org/payments/[SHORT-FORM].

[dret]

On 2016-05-18 07:26, Rouslan Solomakhin wrote:

I think short-form identifiers can be relative URLs under W3C control.
For example,

• |visa| -> https://w3c.org/payments/visa
• |amex| -> https://w3c.org/payments/amex
• etc
  So |[SHORT-FORM]| is a shorthand for
  |https://w3c.org/payments/[SHORT-FORM]|.

just a historical note: this is exactly what RFC 4287 did, and it turned
out that allowing two ways to identify the same thing was not very
robust. implementation support was just not good. so RFC 5988 ended up
deprecating this, and went back to only allowing one lexical identifier.
i think that was a smart decision. allowing aliases always is a tricky
thing; unique identifiers are much more robust.

[dret]

On 2016-05-18 03:28, Adrian Hope-Bailie wrote:

The group has resolved to use absolute URLs as identifers and is now
awaiting a proposal for how short-form identifiers may be implemented

why would you want those? i would recommend to not use those as
"shorthand aliases", as mentioned in a previous comment.

if you want them as "short names", then maybe allow each URI to be
associated with such a short name, but then you once again have the
trouble that you probably need some sort of registry to keep track of
them, prevent name clashes, and support robust resolution.

[sideshowbarker]

I think short-form identifiers can be relative URLs under W3C control. For example,

• visa -> https://w3c.org/payments/visa
• amex -> https://w3c.org/payments/amex
• etc

So [SHORT-FORM] is a shorthand for https://w3c.org/payments/[SHORT-FORM].

It’s unlikely the W3C will agree to host URLs for these identifiers if they’re meant to be resolvable. For some insight into why, see https://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/

There’s no reason why the identifiers would need to be under W3C control. If the WG decides they want to use URLs, the WG should mint any domain name(s) needed for hosting them, and put together a plan for maintaining the resources over the long term.

[adrianhopebailie]

If we can come up with a better way to reduce the verbosity of PMIs when there are multiple sub-classes (like the many card brands for the card payment method) do we even need short dientifiers?

I have proposed using query string parameters in #205 which could mean using:
http://webpayments.org/card/?card-types=[visa,mastercard,amex,diners,jcb]
Instead of:
http://webpayments.org/card/visa, http://webpayments.org/card/mastercard, http://webpayments.org/card/amex, http://webpayments.org/card/diners, http://webpayments.org/card/jcb

Are there reasons other than reducing the verbosity of payment requests for short-names?

[dret]

On 2016-05-24 23:04, Adrian Hope-Bailie wrote:

Are there reasons other than reducing the verbosity of payment requests
for short-names?

in some cases (see RFC 5988 as an example) people like to separate the
identifier namespace into "well-known" (short names that need to be
registered and thus can be used safely) and "extension" (full URIs that
are not supposed to be registered and thus can be used freely and
openly). that's of course just one possible reason of why people might
like short names.

[msporny]

The more I think about this, the more I prefer not attempting to do aliases in v1. Aliases are an optimization that we'll have to figure out how to do in the future (if we find that developers really hate using URLs to identify payment methods). We should have a more complete catalog of all the different PMIs before we try to create single PMI aliases or group PMI aliases.

[dret]

On 2016-05-26 16:42, Manu Sporny wrote:

The more I think about this, the more I prefer not attempting to do
aliases in v1. Aliases are an optimization that we'll have to figure out
how to do in the future... once we have a more complete catalog of all
the different PMIs.

definitely repeating myself here but here we go: aliases are a bad idea
to begin with. even if you started from day 1 you would end up with
implementations that only support/understand the version of the aliased
identifier the developers cared about.

if you introduce aliases later on it gets worse: you'll have deployed
software only supporting the canonical identifiers. if you now throw
aliases into the mix, you can be certain to end up with a brittle mix of
code that only supports the canonical version, and newer code that also
supports the aliases.

it's good to stay away from aliases for now. but just keep it that way.

[adrianhopebailie]

On 26 May the group resolved to not use short-names at this time.