Re: On Settlements

thanks Arie

On Tue, Jun 23, 2015 at 9:37 AM, Arie Yehuda Levy Cohen <
arielevycohen@gmail.com> wrote:

> Pardon me Dan - failed to notice, downloaded and attached. Cheers, Arie
>
>
> --
>
> Heritage & Legacy Advisory | Multi-Generational Wealth Preservation
>
> Arie Y. LEVY-COHEN
> FINANCIAL ADVISOR | INTERNATIONAL CLIENT ADVISOR
> ECONOMICS | FINANCE | BLOCKCHAIN TECH
> PRIVATE WEALTH MANAGEMENT
> P: 917.692.6999
>
> On Tue, Jun 23, 2015 at 9:32 AM, Dan Schutzer <cyberdan250@gmail.com>
> wrote:
>
>> I clicked on link and it says access has expired
>>
>> On Tue, Jun 23, 2015 at 9:27 AM, Arie Yehuda Levy Cohen <
>> arielevycohen@gmail.com> wrote:
>>
>>>
>>> https://slack-files.com/files-pri-safe/T03G789F8-F06MKPGPR/afme_posttradeexplained_jan2015_w-2.pdf?c=1435065473-255fea898391b823f87ecadff74b76b5c043bd62
>>>
>>> --
>>>
>>> Heritage & Legacy Advisory | Multi-Generational Wealth Preservation
>>>
>>> Arie Y. LEVY-COHEN
>>> FINANCIAL ADVISOR | INTERNATIONAL CLIENT ADVISOR
>>> ECONOMICS | FINANCE | BLOCKCHAIN TECH
>>> PRIVATE WEALTH MANAGEMENT
>>> P: 917.692.6999
>>>
>>> On Mon, Jun 22, 2015 at 6:25 AM, Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>
>>>> Hi David,
>>>>
>>>> I'll take a stab at updating this. Some comments inline to clarify.
>>>>
>>>> On 19 June 2015 at 08:03, L. David Baron <dbaron@dbaron.org> wrote:
>>>>
>>>>> Here are two comments on the draft charter at:
>>>>> https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG
>>>>> in particular, on the revision:
>>>>>
>>>>> https://www.w3.org/Payments/IG/wiki/index.php?title=Roadmap/PaymentArchitectureWG&oldid=1995
>>>>>
>>>>> (1) In the Scope section, it currently says:
>>>>>       #  Discovery of available payment instruments that can be used
>>>>>       #  by matching those registered by the payer with those
>>>>>       #  supported by the payee (as defined in the Payment Request).
>>>>>
>>>>>     I think there was agreement in the discussions at the
>>>>>     face-to-face that the selection of payment instrument is done by
>>>>>     the payer, since we don't (for privacy reasons) want to expose
>>>>>     all available payment instruments to the Web site.  This is even
>>>>>     explicitly stated in the following bullet.  Despite that, I
>>>>>     think the term "Discovery" is still a little bit jarring (since
>>>>>     it suggests a discovery API).
>>>>>
>>>>>
>>>> +1 that discovery is possibly the wrong word. You'll recall that this
>>>> did cause some confusion during the use case discussion.
>>>>
>>>> My understanding from the discussion at the face to face was that we
>>>> wanted the recommendation to support openness in support of payment schemes
>>>> and instruments (i.e. The browser shouldn't prevent the user from
>>>> registering any scheme or instrument) but that we didn't want to prescribe
>>>> the algorithm that was used to match registered schemes and instruments
>>>> against those supported by the payee.
>>>>
>>>> At this point I imagine the browser API spec defining that the browser
>>>> MUST allow the user to define which "wallet" they want to use and for this
>>>> "discovery" algorithm to be provided by the wallet. Browser's may ship with
>>>> a default wallet from the day that they support the payment API but if the
>>>> user replaces this with another then the payment request (list of supported
>>>> payment schemes and instruments) must be passed, unaltered, from the
>>>> browser to the "wallet" whenever the payment API is invoked.
>>>>
>>>>
>>>>>     While I don't have a better term to offer, I think at least it
>>>>>     could be clarified more locally by adding a clarifying
>>>>>     statement, such as "so that an instrument can be selected by the
>>>>>     payer" at the end or something like "local to the payer" or
>>>>>     "while keeping information local to the payer".
>>>>>
>>>>
>>>> I am starting to think we will need to use the term "wallet" and also
>>>> define what this means.
>>>>
>>>>
>>>>>
>>>>> (2) Some parts of the "Web Payment Vocabularies 1.0"
>>>>>     deliverable's description seem too specific.  In particular, I'd
>>>>>     like to remove the entire (fourth) bullet point:
>>>>>
>>>>>       #  *  For each vocabulary, the Working Group will create at
>>>>>       #     least a JSON-LD serialization and may create additional
>>>>>       #     serializations (e.g., XML).
>>>>>
>>>>>     I'd prefer that the group not be constrained to those particular
>>>>>     technical solutions.
>>>>>
>>>>
>>>> +1 to a more open charter and leaving the specifics to the WG
>>>>
>>>>
>>>>>     I also wonder whether some of the first three notes in that
>>>>>     section might also be too specific; it's hard for me to tell as
>>>>>     they're far from my areas of expertise.
>>>>>
>>>>> -David
>>>>>   (at flight level 36,000 feet, above Nevada)
>>>>>
>>>>> --
>>>>> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
>>>>> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>>>>>              Before I built a wall I'd ask to know
>>>>>              What I was walling in or walling out,
>>>>>              And to whom I was like to give offense.
>>>>>                - Robert Frost, Mending Wall (1914)
>>>>>
>>>>
>>>>
>>>
>>
>