How are payment apps shared between different browser brands?

[msporny]

Migrating issue from w3c/webpayments#15:

When a user registers a new payment instrument, how is that payment instrument shared between different browser brands? For example, if I register a Visa debit card issued by my bank in Google Chrome on my laptop, when I go to purchase something using my mobile phone, is that same debit card available to me via my Firefox web browser (assuming I've authenticated in some way with both browsers)?

There are a variety of choices here, in order of easiest to implement to hardest to implement:

1. There is no sharing mechanism
2. There is a unified payment instrument export mechanism
3. There is a storage and discovery mechanism that all browsers use to import data from other browsers

I assert that the last bullet point is what we should strive for, but we may need to take baby steps to get there. In any case, we should implement the API as if the third item existed and figure out a way to polyfill our way there.

[ianbjacobs]

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

[mattsaxon]

@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.

[ianbjacobs]

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

[mattsaxon]

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

[mattsaxon]

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.

[adrianhopebailie]

@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.

[ianbjacobs]

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

[burdges]

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.