The architecture document reads...
The user agent determines the intersection...
I believe this should read "The Payment Mediator...."
In addition we should be clear that the payment mediator may optimise the experience, applying knowledge such as user preferences (e.g. preferred payment method) and environmental factors (location).
Note, I will submit a PR post FPWD
+1 to using payment mediator consistently as the primary component.
The browser API spec refers to user agents (not mediators) which is correct as this is a specification for user agents. #137 incorrectly suggests changes to the browser API spec.
The browser API spec MAY refer to the role of payment mediator as a role that the user agent assumes in implementing the API but we should emphasize that some of the functions defined in the spec are not functions of a payment mediator they are functions that are only defined for user agents.
The architecture document should describe the role of a payment mediator which the browser API spec could reference
While I believe the mediator is the primary entity that will match identifiers, I propose that we define the matching in the PMI spec. The complexity of the matching algorithm will depend on the semantics we build in (e.g., grouping and subclassing will increase the complexity).
Matching algo will be defined in the PMI spec