Re: The case for registration as a technical specification

> On 9 Jul 2015, at 16:34, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
> 
> Hi David,
> 
> I agree and I think that the discussion re the charter to date suggests others do too.
> 
> One thing I wanted to clarify is the role of the browser/UA in the currently proposed flow. This is my understanding and I'm happy for anyone to chime in with a different perspective.
> 
> As it stands, the proposal is to create a standard WebIDL API that allows websites to initiate a payment by passing a standardised message to the browser and for that API to respond with a standardised message back to the website. This process will be repeated for a completion request and response.
> 
> When the browser receives this message it should do one of two things:
> Pass it directly to a configured wallet, unmodified
> Decline the API request as there is no wallet configured
> i.e. I'd like the browser's participation in the flow to simply be as a proxy of messages between the website and the user's wallet.
> 
> We are proposing that there may be 3 types of wallet:
> 
> 1. Cloud-based. In which case the browser passes the requests message via HTTP (a REST API of sorts) to the wallet service and get's back a response. (Details of how this would work, including hosting of the wallet UI in a frame or new window will be left to the WG to decide).
> 
> 2. Native. Meaning the user installed some wallet software (or app in the case of a smartphone) and there is a mechanism for the browser to communicate with that native wallet service. It will be for the browser vendors to propose how this is done or if it should be standardised. Perhaps it will be simplest to say that native wallets must host an HTTP endpoint service so that the interface matches cloud-based wallets, or maybe they will need to take the form of browser extensions.
> 
I think we should leave it to the Working Group to decide whether to require an HTTP end point or to support other possibilities as suggested in my talk [1] in the recent New York face to face. I carefully avoided the term “wallet” in my talk and instead used “selection agent” in reference to its function to enable payers to select which payment instrument they want to use for a given transaction. I agree that we need a means to register and unregister selection agents and that the browser is in a good position to support that. Browsers could also play a helpful role for launching payment instruments once selected.  In principle, the browser or the selection agent could act as registrar for payment instruments, however, the selection agent would be in a better position to support a seamless experience across browsers. 

It would be desirable to provide a means to launch and communicate with selection agents and payment instruments in a way that is decoupled from how they are implemented (as native app, browser extension, cloud service, etc.).  This makes it interesting to consider browser APIs that support this.  In particular, a means to launch a registered selection agent/payment instrument, to pass it some data, and later to get back some data.  We already need this for the web page to selection agent interface, and it makes sense to reuse the mechanism for interfacing to payment instruments.  The WG charter could set some broad functional requirements.

Selection agents and payment instruments will need some way to interact with the payer.  We should consider enabling web applications (on behalf of the payee) to provide an IFRAME element for use by selection agents and payment instruments, where these are not native apps.  This has implications for the API between the payee’s web app and the browser.

Whilst the initial charter for the Web Payments WG is focused purely in payments and not the broader commercial or economic transaction, it is clear that we will eventually want to address payee provided receipts, and it would seem not unreasonable for these to be handled by the same agent as the selection agent. In other words, we should ensure that the payment APIs we standardise don’t preclude  future extensions for a (wallet) agent that performs a variety of extended functions, e.g. identity cards, loyalty schemes, receipts, and so forth.


[1] https://www.w3.org/Payments/IG/wiki/images/e/ea/Implementation-considerations.pdf


—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>