Re: Payment Method Identifiers

Hi Adrian,

Here are the main topics you address in your proposal:

 * Syntax (including short names)
 * Equivalence test
 * W3C minting policy

Notes on those topics:

 * Syntax.
   - Ok with absolute URLs working for everyone
   - If any non-absolute URL string is resolved by user agents to a w3.org URL, then that is mild encouragement to people to create
     short strings since they know they will work…but they will look like W3C minted them even though we did not.
   - To avoid that confusion and the proliferation of short strings, it may be preferable to so something like this:
     * There are a few short strings that are aliases for their absolute URI equivalences. These aliases are defined in W3C specs.
     * A conforming user agent MUST transform these aliases into their specified absolute URL equivalents (or behave as though they did).
     * Over time we may decide to publish more of these or we may stick only with absolute URLs.

     Why is this preferable? Because there is no conformance requirement for a user agent that would produce an absolute
     URL that looks like it was minted by W3C but was not.

 * Equivalence test.
   - Please use an existing equivalence test; I suggest the one in the FPWD [1]. I (strongly) suggest we say nothing about https or trailing slash.
   - To prevent the proliferation of short strings, require that only absolute URLs (after conversion of W3C-defined aliases) be tested for equivalence
     Any string that cannot be so converted returns an equivalence of “false” (whatever the other value is).

 * W3C minting policy
   - I don’t yet know what policy we should use, but the W3C minting policy should not be defined in the specification. The specification is
     for implementers. The policy is for W3C groups and does not have an impact on developers. Furthermore, we should be able
     to change it more easily than through the Rec Track process.

Ian


[1] https://www.w3.org/TR/payment-method-id/#identifier-equivalence


> On May 4, 2016, at 6:48 AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
> 
> Zach, thanks for raising this. I started trying to push the payment method identifier related issues up the priority list late last week but need to finish that for the call Thursday.
> 
> +1 on using absolute URLs
> 
> However, I have a slightly different take on the short names debate.
> 
> I don't think any payment method identifier at a URL that is not relative to a base owned by this group (e.g. http://w3.org/payments/WG/methods or similar) should have a short-name. For the many reasons discussed in the issue lists I am strongly against us trying to maintain a public registry and don't think it is necessary - these are just aliases, they are not essential.
> 
> So I am +0 on using short-names, I think they add complexity that is not needed.
> 
> That said, if we do use aliases/short names I propose we do the following:
> 
>  • Any payment method specification that is published by the WG (Basic Card Payments is the first, SEPA is currently an editors draft and therefor a candidate) will define one or more payment method identifiers.
>  • These identifiers will all be absolute URLs and SHOULD all use the same base URL (to be decided what that is, I propose http://w3.org/payments/WG/methods/).
>  • The matching rules for payment method identifiers are preceded by the following normalization rules:
>   • If an identifier is not an absolute URL it must be assumed to be a relative URL with the base http://w3.org/payments/WG/methods/
>   • If an identifier is a URL with the protocol value equal to "https" or not specified set the protocol to "http"
>   • If the last character of the identifier is not the forward-slash '/' character, append a forward-slash '/' to the identifer.
>  • Any new payment method specs that are developed within W3C (or submitted to the W3C to be published in this namespace) will follow the same publishing process. i.e. Through consensus of the WG (or some other group nominated by the WG when our charter is up) a new payment method identifier spec will be adopted as an editors draft and later, also through consensus of the group, published as a working draft and then a note.
>  • Only payment method specs published in this way should use identifiers with the base URL http://w3.org/payments/WG/methods/
>  • The payment method identifier spec should define this process and the normalization rules but also explicitly point out that independently developed payment method specs are encouraged but that they must ONLY use absolute URLs as identifers.
> It's important to note that the whole design of this system was to decouple the designers of a payment method spec from the issuers of payment instruments to create a level playing field and also encourage innovation.
> 
> That is to say, there is nothing preventing an authority over a specific brand of payment instrument (like VISA, MasterCard, UnionPay etc) from defining their own spec but that should not preclude the community from coming up with their one too.
> 
> We (the WG) have decided to bootstrap this by defining a bunch of payment method specs of our own and if, for example, the card companies decide they don't like ours they can either:
> 1. Submit changes to it which the group must agree to adopt OR
> 2. Publish their own and persuade payment app developers and websites/payment processors to use theirs instead or as well
> 
> We have given ourselves the privilege of using short-names for our PMIs because any payment method spec that we publish will have gone through a process that we know to be fair and transparent and this advantage should encourage developers of new specs to use this process.
> 
> The idea is that while it feels like there will be a lot of fragmentation the market will likely force standardization and we get that without limiting innovation or handing control to any specific entity or group. Instead, the success of a payment method standard is down to adoption and that is influenced by a number of factors we can't control (a good thing I think).

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447