Re: Multiple Wallets

RE: "Again, it's unclear if this is an intentionally inflammatory remark or
not"

No, it was a genuine question. When you later say "So, while I speak for
myself (as the original author of those definitions) I believe the group
has spoken for not having them in the charter." ... that's sort of
borderline to speaking on behalf of the group to set aside a suggestion at
least for the FAQ put forward as a potential solution for a word that
appears numerous times in the key document and yet lacks, I contend, a
coherent definition in the FAQ. Anyways, I was just asking in good faith.

RE: "When I asked you previously to explain an email of yours that I
couldn't understand you never replied so you can understand why it's hard
for me to see this debate will be constructive:
https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Jul/0106.html
i.e. "You'll have to explain the difference then because we are clearly
missing each other."

I did reply, just not in the same thread, and two weeks later. (I've had a
very busy two weeks on an unrelated project.):
https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Aug/0003.html
... that reply being part of the proposed solution to the wallet concept
that you oppose for the FAQ in support of the Charter. Let me add that I
was one of the voices on this list that suggested back a while ago to not
use the term wallet, due to its ambiguity amongst diverse participant. But
wallet stuck, so I simply suggest that the current definition in the
Charter with the FAQ is logically problematic.

RE: "The group made the decision that we have hit diminishing marginal
returns bike-shedding the word "wallet" when the charter and FAQ provide
sufficient detail as stand-alone sources for the WG to begin its work and
understand it's scope."
and
RE [Ian Jacobs]: "Let’s remember that this is a charter not a
specification. My read of the group is that it is not cost-effective at
this moment in time (preparing the charter) to develop a more precise
definition.

That the IG chooses to park the definition of "wallet" makes sense. If
that's the case though, the group might consider removing the current
definition which is flawed. The problem is not that it's imprecise. The
problem is that it expresses the repository part (ref my proposal) for
value exachange instruments, but not the depository part (ref my proposal)
for value itself. And yet many of the references in the Charter and FAQ
correctly require the existence of the the depository part.

It remains a mystery to me why this is not accepted as a simple, very
concise and straightforward improvement to the current text. But let's
leave it at that.

Joseph

On Mon, Aug 3, 2015 at 5:55 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

>
>
> On 3 August 2015 at 22:47, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> RE: "Our approach..."
>>
>> Does Adrian speak on behalf of the W3C WPIG on this topic, or as a Member
>> of the W3C WPIG?
>>
>
> To be 100% clear, unless otherwise stated, I always speak on behalf of
> myself and not on behalf of either the IG or Ripple Labs.
>
> Again, it's unclear if this is an intentionally inflammatory remark or not
> but I assume someone who has been engaging on W3C mailing lists to the
> extent that you have should know this.
>
> What I have put forward is my interpretation of the group's consensus
> around the current charter and my thoughts which influenced my input to the
> document.
>
>
>>
>> RE: "the importance of the legalese"
>>
>> I'm sure you understand that's not the point I raised.
>>
>
> No, to be perfectly honest I seldom understand exactly what the point is
> you are trying to raise :)
>
> When I asked you previously to explain an email of yours that I couldn't
> understand you never replied so you can understand why it's hard for me to
> see this debate will be constructive:
> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Jul/0106.html
>
>>
>> To repeat: "My proposal is related to the absolute minimum required"
>> functional premises of a term that is important enough to appears 30 times
>> in the Charter. We can agree to disagree about the importance of deliberate
>> ambiguity about what that term means. Such deliberate ambiguity in a W3C
>> specification in this field seems very unwise to me. So I hope WPIG members
>> will forgive my persistence on the point.
>>
>> RE [David Singer]: "at the moment, the ‘digital wallet’ is like a leather
>> wallet; it holds banknotes, credit cards, and the like (instruments)"
>>
>> Yup:
>> A banknote is a monetary token, and the digital form of that token goes
>> into a depository.
>> A credit card, and an aggregator (like PayPal) are sets of payment
>> algorithms, and they go into a repository.
>> Wallet = Depository + Repostory
>>
>>
> Previous versions of this charter had very similar definitions to yours
> for a wallet (as both repository and depository) and these were thinned out
> at the consensus of the group. So, while I speak for myself (as the
> original author of those definitions) I believe the group has spoken for
> not having them in the charter.
>
> Bare in mind that the purpose of the charter is to outline the work we
> will do with enough granularity to allow large organisations such as
> David's to make the commitment to participate (bare in mind the IP
> commitments they make in doing so) while not so specific as to limit the
> ability of the group to innovate.
>
> The charter is not a specification. When the time comes the WG will define
> the aspects of the service we call a wallet in as much as that definition
> is required (if at all) to produce a specification.
>
>
>> I haven't grasped why my recommendation is controversial.
>>
>
> The group made the decision that we have hit diminishing marginal returns
> bike-shedding the word "wallet" when the charter and FAQ provide sufficient
> detail as stand-alone sources for the WG to begin its work and understand
> it's scope.
>
> Nobody is calling anything you have said controversial. Both Manu, Ian and
> I have all said that while the definition you provide is not incorrect it
> is inappropriate for this document.
>
> That is not to say that the many external organisations you have
> introduced to the group are not important liasons for the IG. I have
> personally added many of them to the External Liaison TF's wiki.
>
>>
>> Joseph Potvin
>>
> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>> On Mon, Aug 3, 2015 at 4:28 PM, Adrian Hope-Bailie <adrian@hopebailie.com
>> > wrote:
>>
>>> Hi Joseph,
>>>
>>> We will have to agree to disagree on the importance of the legalese in
>>> the work of this WG.
>>>
>>> Our approach is that the legal implications of using a particular
>>> payment instrument or payment scheme are not affected by the fact that the
>>> exchange of messages to facilitate this was done in a standardised way.
>>>
>>> The standard will provide a mechanism for new payment schemes to come
>>> about and for existing payment schemes to improve how they are used on the
>>> Web. As to the regulations and laws that govern the use of the scheme,
>>> these are left to the scheme administrators to figure out not the W3C.
>>>
>>> Adrian
>>>
>>> On 3 August 2015 at 21:07, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>
>>>> Adrian,
>>>>
>>>> Any "passive-aggressive" tone is inadvertent. My intention is only to
>>>> address the issues in a straighforward logic-based way.
>>>>
>>>> RE: "The definitions you give are legalese that are from a legal
>>>> standards body and are not useful (in my opinion) in the charter of a WG
>>>> that is working on Web standards the primary audience of which will be
>>>> developers."
>>>> and
>>>> RE: "Why do you consider a definition from "the top-echelon global
>>>> standards body on e-commerce law" more useful than one defined, refined and
>>>> captured by the group who will need to refer to the definition in
>>>> completing their work? UNICTRAL are a valuable resource for the IG but I
>>>> would argue have very little overlap with the WG."
>>>>
>>>> The answer to "why" this overlap is mission-critical was provided to
>>>> RippleLabs a couple of months ago:
>>>> http://www.fincen.gov/news_room/nr/html/20150505.html
>>>> ... Like it or not, the lawyers hold the Aces in this game.
>>>>
>>>> RE: "We will not rigorously define the wallet's functions. i.e. We will
>>>> not define exactly what functionality the wallet will have (only the
>>>> minimum required) so that we leave room for functionality that wallet
>>>> service implementors can dream up to innovate in this area."
>>>>
>>>> My proposal is related to the absolute minimum required. That does, of
>>>> course, require a certain degree of abstraction.
>>>>
>>>> RE: "The phrase payment instrument is linked to the definition in the
>>>> use cases"  ... "payment instrument: A mechanism used to transfer value
>>>> from a payer
>>>> <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payer>
>>>> to a payee
>>>> <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payee>
>>>> .
>>>>
>>>> Sorry I missed that when writing this morning. Now can anyone please
>>>> clarify: IF the Charter states "digital wallet: A wallet is a container for
>>>> payment instruments that affords access to them. A digital wallet holds
>>>> digital payment instruments."  AND IF the Use Case document states "payment
>>>> instrument: A mechanism used to transfer value from a payer
>>>> <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payer>
>>>> to a payee
>>>> <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payee>"
>>>> THEN shall we conclude that a digital wallet, as currently defined by the
>>>> W3C WPIG, cannot hold "value"?  It can only hold "mechanisms used to
>>>> transfer value"? In my propoosed wording, that part would be the
>>>> "repository".  I've simply said that, in addition, the other part of the
>>>> wallet can actually hold "value". That part would be the "depository".
>>>>
>>>> RE: "The definition of payment instrument is quite abstract and allows
>>>> for a scheme to define it however they like as long as it can fulfill the
>>>> functions that will be implicit in the standard"
>>>> and
>>>> RE: "the scheme will define any additional behavior that is required to
>>>> use a payment instrument to process a payment"
>>>>
>>>> RippleLabs already lost that argument, as cited above. "Money" exists
>>>> under certain laws. "NotMoney" exists under other laws. Deliberately
>>>> conflating the two within the terminology of a W3C specification increases
>>>> the risk of errors and omissions on the part of implementers and
>>>> end-users.  Let me pick on here on David Singer's note just now in which
>>>> "payment instrument" could be "e.g. a specific credit card, a $100
>>>> banknote, a specific bitcoin account, and so on". Well, several countries'
>>>> courts have determined that cryptocurrency units are "virtual commodities".
>>>> Therefore trading them for what the courts consider to be "money" is
>>>> subject to sales tax, which is to say, using cryptocurrency units "as"
>>>> currency would consistute tax evasion.
>>>>
>>>> Again, like it or not, the lawyers hold the Aces in this game. However
>>>> some of you might be surprised how forward-thinking and open-minded the
>>>> legal geeks are who participate in fora like UNCITRAL and UNIDROIT. The
>>>> work of the W3C WPIG would be greatly strengthened by integrating its
>>>> concepts about money and payment with them ahead of time, versus after the
>>>> fact through case law experiences.
>>>>
>>>> RE: "This WG is not concerning itself with identity, commerce,
>>>> invoicing, receipts, proof of payment or any other of the many issues that
>>>> are part of "the realm of payments". The WG is concerning itself with a
>>>> more efficient exchange of data between payer and payee to facilitate
>>>> further advancements in all of these areas in time."
>>>>
>>>> An interaction between a payee (eg merchant) and payer (customer) is
>>>> "commerce".
>>>> An interaction between either a payee or payer and the payment system,
>>>> or amongst entities of the payment system, is "financial services".
>>>> ...it's not just me who says so.
>>>>
>>>> Joseph Potvin
>>>> On behalf of DataKinetics http://www.dkl.com
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> jpotvin@opman.ca
>>>> Mobile: 819-593-5983
>>>>
>>>> On Mon, Aug 3, 2015 at 12:53 PM, Adrian Hope-Bailie <
>>>> adrian@hopebailie.com> wrote:
>>>>
>>>>> Hi Joseph,
>>>>>
>>>>> Since it's unclear if the passive-aggressive tone of your email is
>>>>> intentional or not I'll do you the courtesy of responding anyway.
>>>>>
>>>>> The charter and FAQ you are analyzing are for a working group with a
>>>>> very specific scope of work that it is a subset of the greater scope of
>>>>> work payments that the IG is interested in. Specifically, the WG is aiming
>>>>> at standardizing some interfaces between Web applications and user-agents
>>>>> for exchange of messages that may be used to complete a payment in a more
>>>>> efficient manner than is done today. That is all.
>>>>>
>>>>> In doing this it is impossible to proceed without considering the
>>>>> actors immediately connected to the Web application (such as payment
>>>>> processors) and user agent (such as wallet services) and their requirements
>>>>> in completing a payment over the Web so that the interface that is in scope
>>>>> can accommodate these.
>>>>>
>>>>> To be clear, this group is lazer focused on payments and the minimal
>>>>> set of messages and data that must be exchanged to complete a payment.
>>>>> eCommerce is a far wider domain and the WG has explicitly chosen to limit
>>>>> it's scope to not include everything in that domain.
>>>>>
>>>>>
>>>>> On 3 August 2015 at 18:03, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>>>
>>>>>> The issues expressed by some against the proposed working definition
>>>>>> are:
>>>>>>
>>>>>> 1. Some members here don't understand the precise legal terms used by
>>>>>> the top-echelon global standards body on e-commerce law. Which of the terms
>>>>>> are difficult to understand are not specified, so it's impossible to know
>>>>>> what clarify. Perhaps it is clarity itself that is not wanted.
>>>>>>
>>>>>
>>>>> I think Manu has answered this appropriately. The definitons you give
>>>>> are legalese that are from a legal standards body and are not useful (in my
>>>>> opinion) in the charter of a WG that is working on Web standards the
>>>>> primary audience of which will be developers.
>>>>>
>>>>>
>>>>>>
>>>>>> 2. The proposal to ground the proposed generic omni-channel
>>>>>> definition of "wallet" upon the precise legal terms of the top-echelon
>>>>>> global standards body on e-commerce law is perceived to be the same as
>>>>>> pushing preconceived ideas based on this or that particular products out
>>>>>> there today that call themselves in name or otherwise, wallets. Perhaps its
>>>>>> the domain authority of the top-echelon global standards body on e-commerce
>>>>>> law that is rejected.
>>>>>>
>>>>>
>>>>> Why do you consider a definition from "the top-echelon global
>>>>> standards body on e-commerce law" more useful than one defined, refined and
>>>>> captured by the group who will need to refer to the definition in
>>>>> completing their work? UNICTRAL are a valuable resource for the IG but I
>>>>> would argue have very little overlap with the WG.
>>>>>
>>>>>
>>>>>>
>>>>>> 3. "We are explicitly trying to avoid defining too rigorously, the
>>>>>> wallet's FUNCTIONS" although the definition in the Charter is clearly
>>>>>> functional, and the FAQ says "the standard will define some minimum
>>>>>> required functions of a wallet (receiving, processing and responding to the
>>>>>> standard messages in the standard flow) to perform payments on the Web".
>>>>>> The proposal is put forward precisely to express some minimum required
>>>>>> functions "so that we don't restrict the ability of those building systems
>>>>>> that can host that interface, and service those messages from the payee,
>>>>>> from innovating in how they do it".
>>>>>>
>>>>>
>>>>> I don't see the issue. We will define the minimum required functions
>>>>> of the service we are calling a wallet. i.e. Enough to be able to
>>>>> accommodate the interface we will define. We will not rigorously define the
>>>>> wallet's functions. i.e. We will not define exactly what functionality the
>>>>> wallet will have (only the minimum required) so that we leave room for
>>>>> functionality that wallet service implementors can dream up to innovate in
>>>>> this area.
>>>>>
>>>>>
>>>>>>
>>>>>> The word "wallet" appears 30 times in the current charter. The
>>>>>> definition given is: "digital wallet: A wallet is a container for payment
>>>>>> instruments that affords access to them. A digital wallet holds digital
>>>>>> payment instruments."   ...but "payment instruments" is not defined.
>>>>>>
>>>>>
>>>>> The phrase payment instrument is linked to the definition in the use
>>>>> cases:
>>>>> http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payment-instrument
>>>>>
>>>>>
>>>>>>
>>>>>> The proposed definition provides for two general classes of payment
>>>>>> instrument: "money" and "anything else that might be put into the wallet in
>>>>>> support of payments". Which is to say, the proposed definition provides
>>>>>> that in the superclass of "payment instruments", all of us working in this
>>>>>> space absolutely must design whatever systems we are designing to apply
>>>>>> different sets of constraints to wallet contents that are considered in law
>>>>>> to be "money", than to any other types of wallet contents that are "not
>>>>>> money" but something else.
>>>>>>
>>>>>> So let me bring this down to the simplest clarification I'm
>>>>>> attempting to bring foward. The class "PaymentInstruments" includes just
>>>>>> two sub-classes: "Money" and "NotMoney".  To avoid expressing the negative,
>>>>>> maybe it could be "MoneyAssets" and "PaymentRules", but I think I'd stay
>>>>>> with "NotMoney".
>>>>>>
>>>>>
>>>>> I disagree. The definition of payment instrument is quite abstract and
>>>>> allows for a scheme to define it however they like as long as it can
>>>>> fulfill the functions that will be implicit in the standard. While the
>>>>> standard does not yet exist it appears these will be things like:
>>>>> identifiable (have a way of differentiating one instrument from another),
>>>>> serialisable (able to pass an instance or reference to an instance in the
>>>>> messages).
>>>>>
>>>>> Beyond that the scheme will define any additional behavior that is
>>>>> required to use a payment instrument to process a payment. The payment
>>>>> processor and wallet service will need to be able to execute that scheme
>>>>> defined logic in order to claim support for that scheme.
>>>>>
>>>>>
>>>>>>
>>>>>> If this IG cannot bring itself to make that distinction, then I fear
>>>>>> it is setting up users of the eventual specification for a perennial series
>>>>>> of headaches.
>>>>>>
>>>>>> The word "wallet" appears 39 times in the FAQ, which states: "The
>>>>>> discovery algorithm and wallet behavior is not standardised only the format
>>>>>> of the request" ... "Is W3C standardizing a wallet? No. ... the standard
>>>>>> will define some minimum required functions of a wallet (receiving,
>>>>>> processing and responding to the standard messages in the standard flow) to
>>>>>> perform payments on the Web. Because the "digital wallet" concept is useful
>>>>>> as a shorthand, but means different things to different audiences, this
>>>>>> charter includes a definition to clarify the intent of this group."
>>>>>>
>>>>>> For the W3C to engage in work in the realm of payments is an
>>>>>> inherently interdisciplinary endeavour.
>>>>>>
>>>>>
>>>>> Correct. Which is why the scope of this WG is intentionally focused as
>>>>> it is on a very specific set of interactions that, if standardised, will
>>>>> remove a roadblock to more efficient online payment systems and development
>>>>> of new and better payment schemes and instruments specifically target at
>>>>> use on the Web.
>>>>>
>>>>> This WG is not concerning itself with identity, commerce, invoicing,
>>>>> receipts, proof of payment or any other of the many issues that are part of
>>>>> "the realm of payments". The WG is concerning itself with a more efficient
>>>>> exchange of data between payer and payee to facilitate further advancements
>>>>> in all of these areas in time.
>>>>>
>>>>>
>>>>>> The #1 and #2 domains outside of information technology that provide
>>>>>> the logical entities, relationships and constraints for this work are law
>>>>>> and economics, in that order. I come from the #2 domain -- IANAL. But
>>>>>> permit me to suggest that if this IG would like more participation from
>>>>>> global payment systems organizations and financial services companies, then
>>>>>> it will take the time to understand and accomodate certain precise legal
>>>>>> terms which the top-echelon working group of lawyers from around the world
>>>>>> provide for use in the domain of e-commerce and payments.
>>>>>>
>>>>>> Or don't.
>>>>>>
>>>>>
>>>>> Thanks, but for the purposes of this WG I don't think we will. I
>>>>> appreciate the sentiment but as I have said in many round-about ways thus
>>>>> far you are confusing the work of the WG with the wider scope of the IG and
>>>>> therefor a lot of the criticisms you are leveling at the charter and FAQ
>>>>> are simply misplaced.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Joseph Potvin
>>>>>> On behalf of DataKinetics http://www.dkl.com
>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>> The Opman Company | La compagnie Opman
>>>>>> jpotvin@opman.ca
>>>>>> Mobile: 819-593-5983
>>>>>>
>>>>>> On Mon, Aug 3, 2015 at 10:32 AM, Adrian Hope-Bailie <
>>>>>> adrian@hopebailie.com> wrote:
>>>>>>
>>>>>>> It's important to not take a narrow view of the discussion thus-far
>>>>>>> or respond to cherry-picked comments.
>>>>>>>
>>>>>>> @Joseph: I would suggest that you received little buy in for your
>>>>>>> proposal because those definitions are overly complicated and
>>>>>>> highly-abstract and, to be honest, almost impossible to understand. I did
>>>>>>> respond to you at some point asking for further clarity on what you meant
>>>>>>> but that was the end of that thread. Like Jorg I am viewing all of this
>>>>>>> through the lens of a potential working group participant and specifically
>>>>>>> a developer who would have to implement something either as a wallet
>>>>>>> vendor, browser vendor payent processor or other stakeholder.
>>>>>>>
>>>>>>> We should not colour this discussion with preconceived ideas of what
>>>>>>> a wallet is, based on the variety of products out there today that call
>>>>>>> themselves in name or otherwise, wallets.
>>>>>>>
>>>>>>> The wallet, as defined by the group in the charter and FAQ, is a
>>>>>>> service that is the initial entry point for messages from the payee usually
>>>>>>> passed via the user-agent.
>>>>>>>
>>>>>>> The wallet may be a container for payment instruments. It may simply
>>>>>>> be a selection service that is able to discover many other wallet services
>>>>>>> that are all able to process the same message. It may also be a service
>>>>>>> acting on behalf of a depository or be a depository itself.
>>>>>>>
>>>>>>> The point is, we are explicitly trying to avoid defining too
>>>>>>> rigorously, the wallet's FUNCTIONS. Rather we are focusing on the INTERFACE
>>>>>>> into the wallet service so that we don't restrict the ability of those
>>>>>>> building systems that can host that interface, and service those messages
>>>>>>> from the payee, from innovating in how they do it.
>>>>>>>
>>>>>>> Let's understand the requirements a little better as context for how
>>>>>>> we got here:
>>>>>>>
>>>>>>>    1. We are going to get a request from a payee to initiate the
>>>>>>>    payment process and this request should contain all of the ways that the
>>>>>>>    payee is prepared to accept this payment (as well as some other details of
>>>>>>>    the payment).
>>>>>>>    2. There is a requirement for this request to be directed
>>>>>>>    somewhere. If the request is directed at a browser API then the browser
>>>>>>>    must either handle it or proxy it to some service capable of processing the
>>>>>>>    message. For this to work we need a SINGLE service that will take in this
>>>>>>>    message and return a response.
>>>>>>>    3. The service that receives this message must itself, OR
>>>>>>>    through integration with one or more other services, perform some discovery
>>>>>>>    of the payment instruments available from the payer and then, through
>>>>>>>    user-mediation, business rules or a combination of these select a single
>>>>>>>    payment instrument that the payer is going to use to pay and return the
>>>>>>>    details of this back to the payee.
>>>>>>>    4. If the payment instrument selected is from a "pull" scheme
>>>>>>>    then the payee takes the details it received in the response and processes
>>>>>>>    the payment, probably through some payment provider with which it has a
>>>>>>>    relationship for processing payment for that particular scheme. Following
>>>>>>>    this, it sends a 2nd message to the payer to notify them that the payment
>>>>>>>    is complete and will likely get some form of ACK back from the payer to
>>>>>>>    complete the typical request/response flow.
>>>>>>>    5. If the payment instrument selected is from a "push" scheme
>>>>>>>    then the payee sends a 2nd message to the payer requesting them to process
>>>>>>>    the payment. This message ends up at the same service that received the
>>>>>>>    original message from the payee. At this point (from a standardisation
>>>>>>>    perspective) it is not important what happens next. What is important is
>>>>>>>    that the payment is processed and a response comes back to the payee to
>>>>>>>    prove this. The format of this proof is also outside the scope of the
>>>>>>>    standard as it will be scheme dependent.
>>>>>>>    6. As a developer of any componenet that is involved in this
>>>>>>>    flow I need a standardised flow and I need certain fields in the messages I
>>>>>>>    send and receive to be standardised but unless I am doing the payment
>>>>>>>    processing or discovery or executing some other business logic it's fine if
>>>>>>>    the rest of the message is opaque to me.
>>>>>>>
>>>>>>> What is important to note here is that once the standardised
>>>>>>> messages have been passed "out of the Web context" the behaviour of any
>>>>>>> services or compomenets is outside the scope of our standard. There are any
>>>>>>> number of ways that the system beyond the browser API could be architected:
>>>>>>>
>>>>>>>    - The wallet service could be built into the browser OR browsers
>>>>>>>    may define a mechanism for third parties to integrate wallet services.
>>>>>>>    - All payment instruments may be simply data (such as card
>>>>>>>    numbers, Bitcoin keys etc) that are held in some secure storage and used as
>>>>>>>    required to process payments (that would require the wallet service to have
>>>>>>>    business logic on how to process payments for every payment scheme for
>>>>>>>    which it will hold payment instruments) OR the wallet may define a standard
>>>>>>>    interface for payment instruments so that they are more than purely data
>>>>>>>    but can actually execute payment processing logic too.
>>>>>>>    - The scheme specific data that is passed back and forth between
>>>>>>>    payee and payer using the standard messages and flow we define will be
>>>>>>>    opaque to the standard. This makes the standard simple and allows new
>>>>>>>    schemes to emerge easily into the ecosystem.
>>>>>>>    - When the wallet responds with a payment instrument to use that
>>>>>>>    instrument may be one that was registered with the wallet (eg: you add a
>>>>>>>    card to your Google Wallet and Google Wallet returns the actual card
>>>>>>>    instrument as the payment method) or it may be one that is built into the
>>>>>>>    wallet,perhaps even representing the wallet itself. (eg: you add a card to
>>>>>>>    your Google Wallet and Google Wallet returns a "Google Wallet" instrument
>>>>>>>    as the payment method)
>>>>>>>    - Payment schemes are free to define additional hooks or
>>>>>>>    call-outs to other services that are not defined in the standard and the
>>>>>>>    implementer of support of that scheme (wallet vendor, payment scheme
>>>>>>>    adminstrator etc) must simply find a way for those call-outs or hooks to
>>>>>>>    fit into the standardised flow. Let me expand on this a little with some
>>>>>>>    examples:
>>>>>>>       - A card based scheme (typical pull scheme) may decide that
>>>>>>>       it would like payee's to submit an encrypted card number (encrypted with
>>>>>>>       the scheme operator's public key) to the payment processor to process a
>>>>>>>       payment. For this to work the wallet will need to submit this in the
>>>>>>>       response to the payee (see 3 above). Therefor either the wallet (if the
>>>>>>>       business logic sits there) or the payment instrument (if the logic sits
>>>>>>>       there) must prepare this data to send in the response. i.e. It knows which
>>>>>>>       key to use, how to encrypt the data (format, algo etc) and where to put
>>>>>>>       this in the response.
>>>>>>>       - A card based scheme (typical pull scheme) may decide that
>>>>>>>       it would like payee's to submit a one-time-use token instead of a card
>>>>>>>       number to the payment processor to process a payment. For this to work the
>>>>>>>       wallet will need to submit this in the response to the payee (see 3 above).
>>>>>>>       Therefor either the wallet (if the business logic sits there) or the
>>>>>>>       payment instrument (if the logic sits there) must be capable of getting or
>>>>>>>       generating this token either through some call-out to a token provision
>>>>>>>       service or using some hardware based token generation.
>>>>>>>       - A push based scheme like Bitcoin may be supported by a
>>>>>>>       wallet service which holds the user's private key or has secure credentials
>>>>>>>       to access an online Bitcoin wallet. When it comes time for the wallet to
>>>>>>>       process the payment (see 5 above) it sends the payment to the payee's
>>>>>>>       Bitcoin wallet either by submitting the transaction directly to the Bitcoin
>>>>>>>       network or the online Bitcoin wallet API. The nature of Bitcoin means the
>>>>>>>       scheme may define that the "proof" is unneccesary as a transaction
>>>>>>>       reference is sufficient to send back to the payee who can verify the
>>>>>>>       payment themselves by querying the Bitcoin ledger directly.
>>>>>>>
>>>>>>> My understanding of the charter is that all of the above is true. If
>>>>>>> any IG members disagree I'd be interested to hear your comments.
>>>>>>>
>>>>>>> On 3 August 2015 at 14:27, <Joerg.Heuer@telekom.de> wrote:
>>>>>>>
>>>>>>>> Hello Joseph,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If that’s what was intended anyway, I’m happy with it. Perhaps I’m
>>>>>>>> too implementation-oriented to find my way through generic sentences like
>>>>>>>> those you referred to. ;-)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Ciao,
>>>>>>>>
>>>>>>>>                 Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
>>>>>>>> *Sent:* Montag, 3. August 2015 13:41
>>>>>>>>
>>>>>>>> *To:* Web Payments IG
>>>>>>>> *Subject:* Re: Multiple Wallets
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> RE: "being a depository and a repository - in our eyes is the
>>>>>>>> capability to process requests for certain types of transactions and
>>>>>>>> delegate them to the respective services as the user choses (or has them
>>>>>>>> pre-configured)"
>>>>>>>>
>>>>>>>>
>>>>>>>> Joerg,
>>>>>>>>
>>>>>>>> That is precisely what is intended by including the word
>>>>>>>> "algorithm" in "a 'repository' for persistent storage of enduring integral
>>>>>>>> artifacts (e.g. payment method *algorithms*, receipts, coupons,
>>>>>>>> credentials, etc.)".
>>>>>>>>
>>>>>>>> Perhaps it could be more explicitly worded, or if necessary
>>>>>>>> elaborated.
>>>>>>>>
>>>>>>>> Basically, to relate this proposed working definition of an
>>>>>>>> e-wallet to a physical wallet:
>>>>>>>>
>>>>>>>> * It is a "depository" for the temporary storage of information in
>>>>>>>> the form of authorized scalar units of money (as either tokens and/or
>>>>>>>> scalar values in a registry)
>>>>>>>> =
>>>>>>>>
>>>>>>>> * It's where I put my money
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ...and also:
>>>>>>>>
>>>>>>>>
>>>>>>>> * It is a "repository" for persistent storage of enduring integral
>>>>>>>> artifacts (e.g. payment method algorithms, receipts, coupons, credentials,
>>>>>>>> etc.)
>>>>>>>> =
>>>>>>>>
>>>>>>>> * It's where put my credit cards, debit cards, driver's license,
>>>>>>>> transit pass, café card, etc.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Does this address what you have in mind?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Joseph Potvin
>>>>>>>> On behalf of DataKinetics http://www.dkl.com
>>>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>>>> The Opman Company | La compagnie Opman
>>>>>>>> jpotvin@opman.ca
>>>>>>>> Mobile: 819-593-5983
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 3, 2015 at 5:49 AM, <Joerg.Heuer@telekom.de> wrote:
>>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> Another aspect - besides being a depository and a repository - in
>>>>>>>> our eyes is the capability to process requests for certain types of
>>>>>>>> transactions and delegate them to the respective services as the user
>>>>>>>> choses (or has them pre-configured).
>>>>>>>>
>>>>>>>> We need to be aware of the fact that, while several approaches we
>>>>>>>> see today claim to be 'wallets', their inventors have no fundament to make
>>>>>>>> their product as 'neutral' wrt/ payment instruments as my leather wallet
>>>>>>>> is, because there are no such neutral transaction protocols available
>>>>>>>> (yet). It is the lack of what we aim to accomplish, that blurs the word
>>>>>>>> 'wallet' and the semantics associated.
>>>>>>>>
>>>>>>>> I think that our work represents a good example for a wallet that
>>>>>>>> governs the overall transaction but leaves the implementation for a
>>>>>>>> specific instrument open. However, we can do so because we have an R&D
>>>>>>>> prototype not a product. Every product meant to succeed in the market and
>>>>>>>> eventually earn money, will have to do proprietary stuff and tie things
>>>>>>>> together.
>>>>>>>>
>>>>>>>> I believe it's our job, to do the respective disentanglement and
>>>>>>>> come up with specifications that are needed to allow 'Wallets' according to
>>>>>>>> our definition to come into life.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>         Jörg
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Joseph Potvin [mailto:jpotvin@opman.ca]
>>>>>>>> Sent: Samstag, 1. August 2015 13:47
>>>>>>>> To: Web Payments IG
>>>>>>>> Subject: Re: Multiple Wallets
>>>>>>>>
>>>>>>>> RE: "I think it's clear that nobody is talking about the same thing
>>>>>>>> here :)  I think the term "wallet" and "payment instrument" will only make
>>>>>>>> sense in the context of a particular concrete proposal."
>>>>>>>>
>>>>>>>> Given the prominence of the "wallet" concept in the Charter, and
>>>>>>>> given the IG's decision that the Charter will not include work towards
>>>>>>>> standardization of an electronic wallet specification, and yet given the
>>>>>>>> absence of any working definiition of electronic wallet in this or any
>>>>>>>> other reference document, this topic promises to be an inevitable source of
>>>>>>>> lasting debate.
>>>>>>>>
>>>>>>>> In work underway at DataKinetics on a free/libre/open source module
>>>>>>>> to enhance any e-invoice, we required a sufficiently generic and yet
>>>>>>>> semantically specific working definition of any e-wallet so that the
>>>>>>>> requirements for information exchanged between the two could be specified.
>>>>>>>> I suggest the same is required for the other side of the e-wallet, which is
>>>>>>>> any e-payment system.
>>>>>>>>
>>>>>>>> A week ago I offered the following suggestion. I hope it will be
>>>>>>>> okay to repeat myself, as I didn't see any replies on its substance...
>>>>>>>>
>>>>>>>> ***
>>>>>>>> 1. On the topic of wallets:
>>>>>>>>
>>>>>>>> SUGGESTION: There was considerable discussion on this list about
>>>>>>>> whether or not the term "wallet" was helpful or confusing. It appears
>>>>>>>> there's a preference to keep it. Let me therefore suggest the following
>>>>>>>> concise functional definition summarizing our approach at
>>>>>>>> DataKinetics:
>>>>>>>>
>>>>>>>> An e-wallet has two general functions:
>>>>>>>> * It is a "depository" for the temporary storage of information in
>>>>>>>> the form of authorized scalar units of money (as either tokens and/or
>>>>>>>> scalar values in a registry)
>>>>>>>> * It is a "repository" for persistent storage of enduring integral
>>>>>>>> artifacts (e.g. payment method algorithms, receipts, coupons, credentials,
>>>>>>>> etc.)
>>>>>>>>
>>>>>>>> ***
>>>>>>>>
>>>>>>>> In the above, we are attempting to align with the WG IV
>>>>>>>> (e-Commerce) of the United Nations Commission on International Trade Law
>>>>>>>> (UNCITRAL). This top-level global legal standards body distinguishes two
>>>>>>>> systems for the management of electronic transferable records (their most
>>>>>>>> generic term): “registry-based” and “token-based”. A registry contains
>>>>>>>> information about the electronic transferable records including “the
>>>>>>>> identification of a sole owner of the record and of the rights incorporated
>>>>>>>> in that record at any time”. In contrast, a token is an original and unique
>>>>>>>> record, with which a transfer of rights is accomplished through transfer of
>>>>>>>> control over the record itself. A token-based system for electronic
>>>>>>>> payments is similar in its basic procedures to a paper-based payments
>>>>>>>> system.
>>>>>>>> (UNCITRAL, 2012, p. 7) A registry-based payments system implements
>>>>>>>> control via the management of verifiable unique identities; a token-based
>>>>>>>> payments system implements control via the management of verifiable unique
>>>>>>>> tokens.
>>>>>>>>
>>>>>>>> Source: UNCITRAL. (2012). Legal issues relating to the use of
>>>>>>>> electronic transferable records (Version dated 17 August 2012). United
>>>>>>>> Nations Commission on International Trade Law (UNCITRAL), Working Group IV
>>>>>>>> (Electronic Commerce). Forty-sixth Session, Vienna, 29
>>>>>>>> October-2 November 2012. United Nations General Assembly
>>>>>>>> (A/CN.9/WG.IV/WP.118). Retrieved from
>>>>>>>> https://www.uncitral.org/pdf/english/workinggroups/wg_4/WG4-WP_118_e.pdf
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Joseph Potvin
>>>>>>>> On behalf of DataKinetics http://www.dkl.com Operations Manager |
>>>>>>>> Gestionnaire des opérations The Opman Company | La compagnie Opman
>>>>>>>> jpotvin@opman.ca
>>>>>>>> Mobile: 819-593-5983
>>>>>>>>
>>>>>>>> On Fri, Jul 31, 2015 at 11:07 PM, Brett Wilson <brettw@google.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > On Fri, Jul 31, 2015 at 6:56 PM, Mountie Lee <mountie@paygate.net>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> is anybody share the latest link of glossary for wallet, payment
>>>>>>>> scheme, payment instrument?
>>>>>>>> >>
>>>>>>>> >> in the user's view of payment instrument, for example, credit
>>>>>>>> card is
>>>>>>>> >> one of payment instrument.
>>>>>>>> >> google wallet(or apple pay) is the container of payment
>>>>>>>> >> instruments(credit card and/or more)
>>>>>>>> >>
>>>>>>>> >> I thought that the container is the wallet.
>>>>>>>> >>
>>>>>>>> >> to process credit card payment, users may choose google
>>>>>>>> wallet(or apple pay..) when merchant accept it.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > OK, I think it's clear that nobody is talking about the same thing
>>>>>>>> > here :)
>>>>>>>> >
>>>>>>>> > I think the term "wallet" and "payment instrument" will only make
>>>>>>>> sense in the context of a particular concrete proposal. Right now things
>>>>>>>> are too ambiguous for any consensus. I am going to stop worrying about this.
>>>>>>>> >
>>>>>>>> > Brett
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>