Re: [w3c/webpayments-method-identifiers] PROPOSAL: PMI identifies payment method specification, use meta-data for additional granularity (#5)

@adrianhopebailie, thanks for writing this up.

Some additional notes:

 - In both approaches (query string or JSON in the payment request), there are payment method specified terms that participate in the matching algorithm. For instance, the basic card payment method spec would allow people to use the term "brands" with a list of (arbitrary) values. In the above example, the bitcoin payment method spec would define the term "version" and explain how that term is used (e.g., a list of strings that represent version numbers). 

 - One of the ideas we discussed is that when payment request API is called, payment method identifiers could be repeated N times, but with different constraints each time. (Thus they would not be "duplicate PMIs" as long as the constraints are different.) A mediator would then invoke the matching algorithm for each of these PMI/constraint pairs.

- In a world with payment method specific terms (e.g., brands or version) the mediator running the matching algorithm needs some semantics beyond "URL matching" for testing the constraints. Here are some thoughts on that:

   * Subclass matching is likely to be symmetric: There should be a match both when the merchant accepts a superset of what the user has, and when the merchant accepts a subset of what the user has. In both cases, there is some some common subset, justifying the match.
   * Similarly, when there is a given type of constraint on one side (e.g., on brands) and no constraint on the other, that should constitute a match. 
   * For a given constraint, if the nature of the constraint is not subclassing and the values are otherwise different, that should not constitute a match.

- In pseudo-code, a mediator-implemented matching algorithm (independent of any
given payment method) might look like this:

 * Let PMI_M be the set of PMIs-and-constraints specified by the merchant.
 * Let PMI_U be the set of PMIs-and-constraints specified by the user. (Note: The payment app spec will define how this user-side set is computed as input to the matching algorithm.)
 * The algorithm will loop over PMI_M, looking one by one for matches with members of PMI_U. The result of the loop will be the set of all matching members of PMI_U. This data is most useful from the perspective of the matching payment apps.

- Within that loop, let A and B each be any two PMIs-with-constraints that we are comparing. Here is what I expect the mediator will need to know how to do and thus would be part
of the PMI standard:
  * Do an equivalence test on the URL portion.
  * Identify the constraint sets for A and B (which may be empty)
  * Collect the contraint terms common to the A and B constraint sets.
  * Parse each constraint term treating the values as a list of one or more items.
  * Compare items for equivalence or subclass relationships.

Here's a syntax for discussion:  A{term1=item1, item2, term2=item2/itemN} which means:

   - A is the the URL portion, the contraint is between curly braces.
   - The constraint is a list of term/value pairs.
   - Each value is a list of one or more items.
   - Each item may be composed of a series of subclasses separated by "/", with the root class on the left. Thus, "itemN" is a subclass of "item2" in the example.

We want the following to match:

-  A, A
-  A{}, A
-  A{term1=item1}, A
-  A{term1=item1}, A{term2=item5}
-  A{term1=item1}, A{term1=item1}
-  A{term1=item1, item2}, A{term1=item1, item2}
-  A{term1=item1}, A{term1=item1, item2}
-  A{term1=item1}, A{term1=item1/item5, item2}
-  A{term1=item1/item5}, A{term1=item1}
-  A{term1=item1}, A{term1=item1, item2/item5}

And the following not to match:

- A, B
- A{term1=item1}, A{term1=item2}
- A{term1=item1/item5}, A{term1=item1/item6}

The following test by the mediator would result in a match between two PMIs-with-constraints:

    1. The URL parts match (using a simple URL equivalence test) AND
    2. Any of the following is TRUE:
        a. No overlapping constraints. This includes the following cases:
            - Empty contraints for A or B (or both)
            - No overlapping constraint terms between A and B.
        b. At least one successful match for a term T that appears in both A and B. This includes:
            - There is at least one value for T in A that is string equivalent to one value for T in B.
            - There is at least one value for T in A that is a subclass of a value for T in B.
            - There is at least one value for T in B that is a subclass of a value for T in A.

Ian

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-method-identifiers/issues/5#issuecomment-225665121