During the F2F meeting in Sapporo, we heard about a number of different "registration" scenarios.

The WG will need to consider which, if any, of these should be tackled by the group and their relative priority.

Note: there is no consensus on whether any of these mechanisms should be included in the scope of the groups work. They group may decide to pursue some but not all of them.

Registration of payment method

This allows a new way of paying to be installed into a user agent. For example, adding support for bobspay.com to be used as a way of paying.

Registration of user's payment details

This allows a site to add the details for a particular user into a payment method already installed. For example, if the UA already has the ability to pay with a credit card then this would allow a bank site to register a user's specific credit card details (PAN, etc.)

Registration of "wallet" service

This allows registration of a "wallet" service (which might be local or remote). For example, if a user wants to use alicewallet.com for wallet services instead of using a browser-provided wallet, it should be possible for the browser to know about and interact with the wallet service.

Questions

1. How are payment instruments registered? An API call? A platform-specific mechanism?
2. How are payment instruments shared between different browser brands? A discovery process? An export mechanism?

A note from TPAC discussion:

• browser-only service (only works on one browser), optional browser-sync service (eg. Firefox Sync), WebDHT-based service (truly decentralized preference discovery)