Re: Payment Initiation - platform integration

Adrian,

This is, in a sense, how web accessibility implementations work today. Each
OS vendors created an accessibility API (AAPI) that passes a specifided set
of information through the browser to the assistive technologies (AT) that
needs to interpret and interact with browser content.

Using this paradigm the wallet would be like the AT.

I think it is a superb spproach/idea whether or not Web Notifications turns
out to be the vehicle that can acheive this or not. It sounds plausible
though.

Katie Haritos-Shea
703-371-5545
On Sep 16, 2015 6:42 AM, "Joseph Potvin" <jpotvin@opman.ca> wrote:

> Is there agreement that:
>
> 1. Payment is always specified and initiated from an invoice?
>
> 2. UBL 2.1 provides the relevant global standard for an invoice?
> http://ubl.xml.org/
>
> Joseph Potvin
> Project Coordinator, DataKinetics
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>
> On Wed, Sep 16, 2015 at 5:45 AM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>> Looking at the draft spec from Digital Bazaar for the CG and considering
>> both, our language in the charter, and also some of the comments from the
>> charter AC review I wondered what precedent there may be in defining how a
>> browser should process an API call that requires interaction with the
>> platform (host OS).
>>
>> The best example I could find is in the Web Notifications PR published
>> earlier this month:
>> http://www.w3.org/TR/2015/PR-notifications-20150910/#displaying-notifications
>>
>> I would like to get the groups' (both IG and CG) views on the parallels
>> here between the action "Displaying Notifications" from the Web
>> Notifications recommendation and a potential "Initiating Payments" section
>> we'd put in a recommendation from our WG.
>>
>> The pertinent line from the Web Notifications rec is:
>> "Display notification on the device (*e.g. by making the appropriate
>> notification platform API call*)." - emphasis mine.
>>
>> While I know not all platforms upon which browser's run today have mature
>> "payment APIs" in the same way that they have relativley mature
>> "notifications APIs" this open-ended approach seems appealing in that it
>> avoids the browser needing to become complex payment processing
>> applications.
>>
>> Rather, the messages passed to the navigator.payments API in the browser
>> should simply be passed directly to the platform's payment API (following
>> any security or privacy scrutiny or permissions checks we define).
>>
>> The timing seems right for us to work with the platform vendors (many of
>> whom are also browser vendors that have expressed interest in working on
>> this problem) to define a common vocabulary and logical messages for this
>> flow.
>>
>>
>> *Example:*
>> On a mobile platform I see this working similarly to the way Android
>> intents may function. The browser passes the payment initiatiation request
>> to the platform and the user is prompted with the app selection dialogue
>> they are accustomed to for selecting the app they want to use for that
>> action (the same way you select which app to use when sharing a photo for
>> example).
>>
>> Thoughts?
>>
>
>