Re: On Settlements

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)
>>>>
>>>
>>>
>>
>