How are payment apps shared between different browser brands? about payment-request HOT 8 CLOSED

Centralized registration data is convenient but IMO not mandatory for v1.

Could be done with a centralized payment app manager that invokes the API? The user tells the payment app manager: "Please keep the following browsers I have installed aware of my payment apps" and the manager invokes the API for each browser.

Ian

from payment-request.

@adrianhopebailie, re: comment on PR #73 I think this depends on the view of the WG with regard to the following statement in the Architecture document

We expect that user agents will primarily act as payment mediators in this architecture.

This really is saying that browser will act as payment mediators, but I believe we should be allowing ,in the architecture, for a way for a user-agent to delegate to a 3rd party mediator. Furthermore the allowance for a user to choose to register a 3rd party mediator could be part of the conformance to the specification. This would create a more open ecosystem.

If we interpret the statement literally, whilst browser may be the "primary mediator", we must, to fulfil the architecture allow for an extensibility mechanism as I describe above, i.e. to enable non-primary mediators.

from payment-request.

It is already the case that any piece of software could implement the API. You could be in the middle of your favorite photo editing tool and pay for some filters using the API if the photo editing tool supports the API.

Delegation of the mediator role does not seem to me to be a v1 feature in any case.

Ian

from payment-request.

I'm suggesting that user-agent and mediator in the architecture are different actors and we should define an interface between them.

from payment-request.

I'd be happy with this not being V1 though, but we really do need to update our (the IG) use cases documents to track these V2+ items. Or create an alternative approach to tracking requirements.

from payment-request.

@mattsaxon

I'm suggesting that user-agent and mediator in the architecture are different actors and we should define an interface between them.

I would state this differently. User agent and mediator are different roles and may be different actors depending on the deployment scenario. I think that in the traditional web browser scenario that the user agent and mediator will be the same actor and we don't need to define an interface between them.

That is not to say that browsers may not provide an extension point to allow users to use a different external mediator however I don't think we can mandate this in the spec any more than we can mandate that browsers allow any other extension.

I'd like the HTTP interfaces to be defined for both mediators and apps and then if a browser offered the ability to configure an external mediator they'd likely use the HTTP interface.

from payment-request.

In the extensibility notes [1], Manu indicated that ";While it's true that sharing of registration information is not required with other mediators, that said, centralizing the information isn't the only way to solve the problem. Not saying we can do this for v1, but I think we should be strongly opposed to centralized solutions unless there is no other viable alternative."

Consequently, I am closing this issue which is about "shared between different browser brands".

@msporny, are you ok if we raise a different issue about how mediators remain aware of updates to payment apps?

UPDATE: We have an issue on this already:
w3c/webpayments#111

Ian

[1] https://github.com/w3c/webpayments/wiki/Extensibility_Notes

from payment-request.

I missed this issue before, but I should point out :

There is a serious security threat in sharing payment app registrations between different browsers and different profiles of the same browsers because people do manage their web exposure by using different browsers. It's easy to click too far through common menus and accidentally reveal a shipping address to a site that you want to buy from but must not learn your address.

Examples :

• It's not so strange to configure different browsers differently, or use browser profiles, for different sorts of activities, like to isolate Google+, Gmail, etc. from Google Maps.
• Anyone using Tor Browser probably has a normal browsers they use in special contexts.
• It's reasonable to imagine a family machine separating users using browser profiles instead of system users.

from payment-request.