- From: <msporny@digitalbazaar.com>
- Date: Wed, 24 Sep 2014 14:04:14 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes
for this week's Web Payments telecon are now available:
https://web-payments.org/minutes/2014-09-24/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2014-09-24
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2014Sep/0121.html
Topics:
1. W3C TPAC and Web Payments announcement
2. Payment Processor Selection
3. Wallet Portability
4. Payment Tokens
5. Legacy Payment Systems
6. Multiple authorization levels
7. Smart Contracts
8. Machine-readable licenses
9. Unclassified/Unreviewed use cases
10. Voting on the Use Cases
Resolutions:
1. There will be a vote on all of the use cases that the group
has revised over the past 3 months with an option to make
additional comments on each individual use case.
2. Open a vote by the end of the week on the whether or not to
accept the use case document as the CG's official position, the
vote will be open for 2 weeks from the time the polls open.
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, Pindar Wong, David I. Lehn, Evgeny
Vinogradov, Timothy Holborn
Audio:
https://web-payments.org/minutes/2014-09-24/audio.ogg
Dave Longley is scribing.
Manu Sporny: We're doing a use case super-session today to get
all of these use cases into a position where the Web Payments CG
can vote on whether or not we want to use them, etc.
Manu Sporny: Then we can take them to the Web Payments IG as
input to help speed things along.
Manu Sporny: There are seven use cases left and hopefully we can
get it done in 1.5 hours.
Manu Sporny: We'll put them into a document that can be voted on
by the community after that.
Pindar Wong: All clear.
David I. Lehn: Sounds good.
Topic: W3C TPAC and Web Payments announcement
Pindar Wong: Sorry I won't be able to make this meeting if it
proceeds at such short notice
Manu Sporny: I've got some good news from W3C TPAC -- an
announcement.
Manu Sporny: The TPAC registration form now includes the Web
Payments work
Manu Sporny: https://www.w3.org/2002/09/wbs/35125/TPAC2014/?login
Pindar Wong: Excellent. Excellent Excellent
Pindar Wong: I'll inform those concerned in this part of the
world!
Pindar Wong: In Asia Pacific that is
Manu Sporny: This is excellent news so we can finally tell
people to register and we can get a count of the people who are
attending for the Web Payments work.
Manu Sporny: We may want to make a lot of noise with the people
who have already with TPAC to make sure to check that item if
they want to join the Web Payments work.
Pindar Wong: Thanks to all ... this is now very clear
Pindar Wong: Back to use cases
Topic: Payment Processor Selection
Pindar Wong: Thanks for preparing this -
https://www.w3.org/community/webpayments/wiki/index.php?title=UseCases&diff=916&oldid=913
Manu Sporny: First up is this use case: A buyer goes to a
merchant website, and upon initiating a payment, the merchant's
software transmits the merchant's payment processor options to
the buyer's software. The buyer's software presents a choice of
payment processors the buyer has previously registered with that
are compatible with the merchant's payment processors.
Manu Sporny: Jorge's feedback: NASCAR problem
Manu Sporny: As with his other responses he doesn't understand
that this is a solution to the NASCAR problem.
Manu Sporny: The payment processor choice information will be
transmitted and only one button will be shown.
Dave Longley: Let's not say it will be one button, rather it
will only be showing the options that the user is interested in,
which will also likely be configurable (defaults, etc.) in their
user agent.
Manu Sporny: Michael Williams' feedback: not sure how different
from "Use Case: When a customer intends to make a payment, they
are given a choice to pick among the intersection of the payment
processors they're registered with and the payment processors
that are advertised by the merchant."
Manu Sporny: Michael is right, it's redundant
Dave Longley: Yeah, I agree. [scribe assist by Manu Sporny]
Pindar Wong: So we should scrap it right?
Dave Longley: Yes
Pindar Wong: OK.
Manu Sporny: Response to Jorge - There is agreement that this
isn't a NASCAR problem, there seems to be some misunderstanding
around how the system is intended to work.
Manu Sporny: Yes.
Manu Sporny: Response to Michael - Michael is correct, this does
seem to duplicate 100% of the functionality expressed by the use
case he refers to. We should strike this use case as a duplicate.
Topic: Wallet Portability
Manu Sporny: Next use case is - An entity (payer, payee,
merchant, buyer) stores their wallet, credentials, and digital
receipts with a particular identity/wallet/data storage provider.
The entity decides to switch to a different identity/wallet/data
storage provider and all of their wallet, receipt, and credential
data comes with them.
Manu Sporny: Jorge's feedback - the capability of switching
wallet hosting providers would be great, but I guess it would be
hard to achieve if there is balance to be transferred that would
imply one provider sending actual money to another.
Dave Longley: We missed a use case -- we can go back to that one
after this one.
Manu Sporny: In the future if we're going to be able to do
clearing in an immediate manner, then that means that this
capability that money moves with all the other information has to
hold. The technology we have right now can transfer all the
information because it's all linked information, so we have
mechanisms to transmit that or we don't think they are that
difficult to create, and if we have a system to do clearing that
actually moves money from one payment processor to another then
the use case can be achievable.
Pindar Wong: Just because you can does it mean you should?
Pindar Wong: Unintended consequences?
Evgeny Vinogradov: One of the possibilities ... when you are
recording payments, merchants can store other information -- so
if we remove the word "their" then that opens up the use case.
Manu Sporny: Now the use case reads: An entity (payer, payee,
merchant, buyer) stores wallet, credentials, and digital receipts
with a particular identity/wallet/data storage provider. The
entity decides to switch to a different identity/wallet/data
storage provider and all wallet, receipt, and credential data
comes with them.
Manu Sporny: Evgeny, does that updated text work for you?
Evgeny Vinogradov: Yes.
Pindar Wong: OK... I think I understand what just happened and am
fine with removal of 'their'
Topic: Payment Tokens
Manu Sporny: Next use case - A buyer visits a merchant's website
and initiates a payment. Their payment processor presents them
with an option to subscribe or add a pay-as-you-go token for
future purchases from the merchant.
Manu Sporny: This is effectively tokenization, it's a way to
support subscription.
Manu Sporny: Jorge's feedback - Pay-as-you-go tokens sound good,
but what about choosing the payment processor first?
Manu Sporny: We have other use cases for choosing the payment
processor.
Pindar Wong: OK
Dave Longley: Separation of concerns; this is an additional
featur.e
Dave Longley: Yes, there is a separation of concerns here - pay
as you go token is separate from choosing your payment processor
[scribe assist by Manu Sporny]
Manu Sporny: Response to Jorge - The selection of the payment
process is handled by the following Use Case: When a payee
intends to make a payment, they are given a choice to pick among
the intersection of the payment processors they're registered
with and the payment processors that are advertised by the
merchant/payee.
Dave Longley: This is also more than subscription.
Timothy Holborn: Is pay-as-you-go different from subscribe?
[scribe assist by Manu Sporny]
Pindar Wong: No zero balance?
Dave Longley: Pay-as-you-go could be viewed as subscribe, but
viewed as something else. As you pay for things on the website,
you're willing to give additional confirmation steps. That's
slightly different from subscribe, which is that you're signing
up for a membership that will be charged to your account every so
often, you could use pay-as-you-go to authorize subscription.
[scribe assist by Manu Sporny]
Dave Longley: You could implement this a variety of ways - you
go to buy something on the site, your payment processor gives you
the option to pre-authorize up to $10/month in transactions from
the merchant/site. [scribe assist by Manu Sporny]
Dave Longley: You could also hand over a payment token to the
merchant, so different ways to do it. [scribe assist by Manu
Sporny]
Timothy Holborn: Subscribe is usually a monthly recurring
charge, you agree to a certain amount to be withdrawn from you
account on a certain interval. [scribe assist by Manu Sporny]
Timothy Holborn: Pay as you go could be done in an ad-hoc
manner. Those are potentially two separate products. [scribe
assist by Manu Sporny]
Dave Longley: Those are two different products, my only point is
that they can be implemented using the same mechanism. [scribe
assist by Manu Sporny]
Timothy Holborn: Subscription usually refers to a monthly
reoccuring charge, you agree to some amount being taken out
periodically. Pay-as-you-go is more like you pay when you use a
product.
Manu Sporny: I agree with Dave in that we found that when we
went to implement this they work in the same way, but at a
high-level we should say there are two use cases.
Pindar Wong: Agree with manu's description to clarify the two
different 'use' cases regardless that they may be imlemented the
same way
Dave Longley: I still want you to show me a receipt when a
purchase happens vs. I don't want to be shown a receipt, just do
the purchase behind the scenes. [scribe assist by Manu Sporny]
Timothy Holborn: A subscription is a periodic basis, the other
kind is a non-periodic basis (maybe with a cap) [scribe assist by
Manu Sporny]
Timothy Holborn: Is a payment processor required to make a
transfer that then gives credits? Rather than offer pay as you
go. [scribe assist by Manu Sporny]
Manu Sporny: Let's split the use case because it confuses what
we're trying to do.
Manu Sporny: One will be for a regular subscription, where the
customer isn't informed asked for payment, the other is
pay-as-you-go the customer needs to be shown a receipt or asked
if it's ok to send the money.
Pindar Wong: Yup
Timothy Holborn: +1
Pindar Wong: +1
Manu Sporny: So, here's the first part of the split use case - A
buyer visits a merchant's website and initiates a payment. Their
payment processor presents them with an option to subscribe to a
merchant's product or service, which will result in periodic
payments at a known value to the merchant.
Pindar Wong: Works for me
Timothy Holborn: +1
Dave Longley: +1
Timothy Holborn: Actually, agreed valued.
Timothy Holborn: Or known value to the merchant? does this mean
the customer knows the value too?
Dave Longley: There is a distinction between these two uses
cases, when you're doing a subscription - you're pushing to
merchants account. With pay-as-you-go, merchant pulls money from
customer. [scribe assist by Manu Sporny]
Dave Longley: With in-app payments, it's the merchant that's
going to be requesting payment. The token has to exist, the
merchant is going to be using a back-end payment initiation
request, which uses the token. [scribe assist by Manu Sporny]
Timothy Holborn: Is it similar to a credit card? [scribe assist
by Manu Sporny]
Dave Longley: In this case, you're not transmitting credit card
information to the merchant. [scribe assist by Manu Sporny]
Timothy Holborn: Is this a limitless pay as you go token?
[scribe assist by Manu Sporny]
Dave Longley: We're not at all suggesting it should be
limitless. There are some set of parameters that have to be met.
For example, "This pay as you go token is limited to $10/month"
[scribe assist by Manu Sporny]
Dave Longley: There could be other parameters that fit in there
as well, it's definitely not limitless. [scribe assist by Manu
Sporny]
Timothy Holborn: In the credit card world, they can
preauthorize, limit up to a certain amount. [scribe assist by
Manu Sporny]
Dave Longley: That's not what preauth does, preauth puts funds
aside for the merchant. It's not intended to do what we're
talking about here. [scribe assist by Manu Sporny]
Pindar Wong: Sorry I'm lost. What's the problem?
Dave Longley: We could say it's similar, we can't say it's a
precedent, but we can't say it's the same thing. [scribe assist
by Manu Sporny]
Manu Sporny: Credit card preauth is a hold of funds to ensure
the merchant can get their funds. It's not the same thing as the
pay-as-you-go thing we're discussing right now.
Dave Longley: It prevents the customer from being able to spend
their own credit.
Manu Sporny: Here the merchant isn't placing a hold on the
funds, but they are able to charge up to, for instance,
$10/month.
Timothy Holborn: Is there a clearing issue here?
Manu Sporny: The credit card issue is a merchant business model
issue -- the idea is to put a hold on some amount of money to
ensure the merchant can collect their funds. The merchant can
hold those funds between when the customer says they intend to
purchase and when they actually do -- or they can delay shipment,
etc. this gets complicated, etc.
Dave Longley: This is intended to work almost exactly the same
way as an interactive purchase. It's designed to be a
non-interactive way of buying. You're just skipping some steps
here. [scribe assist by Manu Sporny]
Pindar Wong: Make a side note w.r.t. hold of funds
Pindar Wong: Kick it to the IG
Dave Longley: We've had discussions about escrow wrt. hold on
funds, etc. We dont' have use cases for it yet. [scribe assist by
Manu Sporny]
Pindar Wong: Good point Tim.
Manu Sporny: Ok, let's make a side note that we don't have that
use case and then head back to the current use case.
Manu Sporny: So, here's the split use case - A buyer visits a
merchant's website and initiates a payment. Their payment
processor presents them with an option to assign a pay-as-you-go
token with a specific spending limit for future purchases with
the merchant. An option is also presented to require the display
of a receipt when a purchase occurs, or to perform the purchase
in the background with no display of the purchase process.
Timothy Holborn: +1
Dave Longley: +1
Pindar Wong: +1
Pindar Wong: Do we say no display or no interaction?
Pindar Wong: Thanks
Timothy Holborn: :)
Pindar Wong: No interruptive display
Dave Longley: What about in-app purchase process - it could be
non-interactive wrt. the payment processor, but interactive wrt.
the game. [scribe assist by Manu Sporny]
Timothy Holborn: Not required.
Timothy Holborn: Ie: optional
Pindar Wong: I like it
Manu Sporny: So, new language - A buyer visits a merchant's
website and initiates a payment. Their payment processor presents
them with an option to assign a pay-as-you-go token with a
specific spending limit for future purchases with the merchant.
An option is also presented to require the display of a receipt
when a purchase occurs, or to perform the purchase in the
background with no interactive purchase process required.
Pindar Wong: Don't forget this is a huge business
Pindar Wong: +1
Dave Longley: +1
Pindar Wong: If the parent sets it up then it should be fine
Manu Sporny: We looked into this quite a bit, there are number
of online child protection acts, etc. assuming we meet those
regulations, parents can set up children with certain accounts
with amounts of money or they can assign pay-as-you-go tokens
with spending limits to their children, and optionally the
payment processor can send some kind of notification (email/text)
when purchases happen so parents can follow purchase history.
Timothy Holborn: What about authorization aspect?
Manu Sporny: There is always an authorization aspect, and there
are multiple ways to handle it, I think we cover them,
subscription, pay-as-you-go, etc. and on top of that you can do
"notify me when this token is used, etc."
Manu Sporny: All those things build off of these base use cases
and are value adds that a payment processor can do.
Manu Sporny: What I thought you might be saying is "Why don't we
add use cases for children spending limits, etc." but I don't
know if that would buy us much except that people know it works
for that sort of use case.
Pindar Wong: You can build on these base use cases
Pindar Wong: For other cases that we've not thought of yet or
models that have yet to emerge
Timothy Holborn: I was just saying parents may not want to allow
children to use these preauthorized tokens (?).
Topic: Legacy Payment Systems
Manu Sporny: Next up - Design Criteria: Ensure the Web payments
solution can provide an abstraction layer that integrates with
existing payment methods (eg: VISA, Mastercard, ACH, PayPal,
debit card, Premium SMS, etc.)
Manu Sporny: Jorge's feedback - Compatibility is always good, but
sometimes complicated, and even more for the entry-level payment
provider trying to achieve PCI compliance. Excluding SMS, this is
very high-end, and doesn't apply to the 2.5 billion unbanked.
Manu Sporny: While true, focusing on 2.5 billion unbanked is
important.
Timothy Holborn: With the micro-payment (pre-authorisation)
use-case, whilst in many use-cases of that particular high-level
use-case - the user may not want to be bothered. one area of
use-cases, may be children using a game that has ‘in-app’
purchases; in which case, authorisation may be required (by the
parent, for example.). Sounds like we’ve got that covered in
other areas though. (per discussion with Manu.. ) [scribe assist
by Timothy Holborn]
Dave Longley: One comment in response to entry level payment
providers, we are not saying a payment provider MUST support
legacy payment systems... they may support legacy ones, they may
not. [scribe assist by Manu Sporny]
Pindar Wong: Agree with must->may finesse
Manu Sporny: If a payment processor wants to come online and
only support bitcoin, that's fine. If one wants to support the
full array of options including shipping gold bullion, they may
do so.
Manu Sporny: Response to Jorge - Focusing on the 2.5B unbanked is
a priority for the group, but in order to get traction, we can't
ignore also supporting legacy systems. We believe this is
achievable given the right level of abstraction, and have
experimental software implementation proofs of concept to
demonstrate integration with legacy systems.
Pindar Wong: Yup
Timothy Holborn: +1
Dave Longley: It's fine, I do think we should mention it being
difficult for new payment processors. we should mention that it's
not required for new payment processors to support older legacy
systems, and if they did support it it would be compatible.
[scribe assist by Manu Sporny]
Pindar Wong: I'm not comfortable with the defniion of 'new'
Timothy Holborn: How about emerging?
Dave Longley: We can use "entry-level" like Jorge said.
Manu Sporny: This is what we have now - Response to Jorge -
Focusing on the 2.5B unbanked is a priority for the group, but in
order to get traction, we can't ignore also supporting legacy
systems. We believe this is achievable given the right level of
abstraction, and have experimental software implementation proofs
of concept to demonstrate integration with legacy systems. We are
not saying a payment provider MUST support legacy payment
systems. They may support legacy ones, they may not.
Pindar Wong: I like this much better
Dave Longley: +1
Topic: Multiple authorization levels
Manu Sporny: Currently we have: Do not prevent multiple levels of
security based on the type of transaction being performed. No
auth for small amounts, PIN auth for medium amounts, Secure
Element for large amounts.
Manu Sporny: Steven Rowat and Michael's feedback is: would it be
possible to avoid the opening double negative, say by using a
single positive, such as "Allow multiple levels..." and "Allow
the implementation..." ?
Manu Sporny: Basically, changing it to this: Design Criteria:
Allow multiple levels of security based on the type of
transaction being performed. No auth for small amounts, PIN auth
for medium amounts, Secure Element for large amounts.
Dave Longley: We explicitly chose the double negative, we didn't
want to prevent it, we didn't want to put it in the spec. [scribe
assist by Manu Sporny]
Dave Longley: "Allow payment processors to choose to use
multiple levels..."
Manu Sporny: This is what I put in there - Allow payment
processors to choose to use multiple levels of security based on
the type of transaction being performed. For example: No auth for
small amounts, PIN auth for medium amounts, Secure Element for
large amounts.
Dave Longley: Allow payment processors to optionally define
multiple levels of required authorization based on the type of
transaction being performed. No auth for small amounts, PIN auth
for medium amounts, Secure Element for large amounts.
Timothy Holborn: “Allow payment processor to define multiple
levels of security based on the type of transaction being
performed."
Pindar Wong: Still thinking
Dave Longley: "Allow payment processors to define the required
level of authorization for particular transactions based on their
preferences and local regulations."
Manu Sporny: I have no strong feelings, Dave's may be overly
specific, Tim's is less specific, don't know if that's good..
[scribe assist by Manu Sporny]
Pindar Wong: Define could be zero
Pindar Wong: OK ... that works for me
Manu Sporny: So, this is what we're settling on? Design Criteria:
Allow payment processors to define the required level of
authorization for particular transactions based on their
preferences and local regulations. For example: No auth for small
amounts, PIN auth for medium amounts, Secure Element for large
amounts.
Dave Longley: +1
Pindar Wong: +1
Timothy Holborn: +1
David I. Lehn: +1
Topic: Smart Contracts
Manu Sporny: We currently have - Design Criteria: Do not prevent
the implementation of simple digital contracts and smart
contracts.
Timothy Holborn: ECHO - if not talking please mute MIC
Manu Sporny: Steven Rowat's feedback - Would it be possible to
avoid the opening double negative, say by using a single
positive, such as "Allow multiple levels..." and "Allow the
implementation..." ?
Manu Sporny: Michael Williams's feedback - double negative "don't
prevent" is confusing, maybe allow?
Dave Longley: "Ensure the technology permits the optional
implementation of simple digital contracts and smart contracts."
Evgeny Vinogradov: Let's not forget that there are other
partners that may require authorization, let's not restrict it to
just payment processors. [scribe assist by Manu Sporny]
Pindar Wong: Very good point
Evgeny Vinogradov: So, we shouldn't use 'choose', we should use
'define' because it enables payment processors to create new
mechanisms of authorization. [scribe assist by Manu Sporny]
Pindar Wong: Can you paste the text?
Manu Sporny: Pindar, currently we have - Design Criteria: Ensure
the technology allows the optional implementation of simple
digital contracts and smart contracts.
Timothy Holborn: What about 'support'? [scribe assist by Manu
Sporny]
Dave Longley: We specifically don't want to do that because we
don't want to build that into this version of the technology.
[scribe assist by Manu Sporny]
Dave Longley: "Ensure the technology allows simple digital
contracts or smart contracts to be layered on top of it" ?
Pindar Wong: Thanks
Dave Longley: Trying to think about a way of saying "Does not
restrict". [scribe assist by Manu Sporny]
Timothy Holborn: We may want to specify that this goes w/ a
particular release. [scribe assist by Manu Sporny]
Timothy Holborn: Smart contracts / parametric contracts may be
with a future release. [scribe assist by Manu Sporny]
Dave Longley: "Ensure the technology can be later extended to
support ..." ?
Dave Longley: "Ensure the technology can be extended or does not
prohibit the implementation of..."?
Pindar Wong: Evolve
Manu Sporny: We want to build in a path of evolution like pindar
says.
Dave Longley: We want people to be able to innovate on top of
version 1 Web Payments technology, so the design criteria are a
way of trying to get that to happen. [scribe assist by Manu
Sporny]
Timothy Holborn: “Enable interoperability with digital contracts,
parametric and smart contract projects with aligned design
criteria'
Timothy Holborn: Um.
Manu Sporny: So, here's the current proposal: Ensure the
technology can be extended or does not prohibit the
implementation of simple digital contracts and smart contracts.
Pindar Wong: I like the last version of Dave's text
Pindar Wong: OK works for me
Dave Longley: +1
Pindar Wong: +1
Timothy Holborn: +1
Topic: Machine-readable licenses
Manu Sporny: We currently have Use Case: A payer purchases access
to a service on a payee's website. Included in their digital
receipt is a machine-readable license (rights and
responsibilities) that indicates what kind of access they've been
granted and for how long. The payee can use this machine-readable
license to enforce access to the service.
Manu Sporny: Feedback from Adrian is that this shouldn't be a
version 1.0 feature.
Manu Sporny: Response to Adrian could be -While it isn't required
for the first iteration, the use case can be achieved via a
single vocabulary term and URL in the digital receipt. The group
shouldn't attempt to define the vocabulary terminology to express
the machine-readable license, but rather provide a hook for
another group such as the ODRL community or Creative Commons to
define what this looks vocabulary looks like.
Timothy Holborn: Did we miss: “ A payment processor tracks
mandatory financial regulatory events and submits
machine-readable information to a regulator-provided URL to
automatically meet regulatory compliance.”
Dave Longley: I think we might want to mention that JSON-LD has
a lot to do with this use case. We use a technology that allows
domain-specific vocabularies to be included into digital
receipts, there's not much that needs to be done to achieve the
use case. [scribe assist by Manu Sporny]
Pindar Wong: One of the problems is that the capabilities of
JSON-LD is not widely known (yet)
Manu Sporny: It makes it sound like we are going to define the
license/rights vocabulary. [scribe assist by Manu Sporny]
Dave Longley: Maybe this should be a design criteria instead of
a use case. [scribe assist by Manu Sporny]
Pindar Wong: Agree that it should be a design criteria
Pindar Wong: Smart move
Pindar Wong: For tading in virtual goods for example
Dave Longley: "Allow the digital receipt format to include
domain-specific vocabulary information to support use cases such
as including machine-readable license information that can be
later used to obtain access to a service."
Timothy Holborn: Why are we being specific about licenses?
Perishable goods are a bigger industry, why not them? For
example, food needs to be tracked, this is about generic linked
data expression in digital licenses. [scribe assist by Manu
Sporny]
Pindar Wong: Yup ... I like this wording
Pindar Wong: GS-1 identifiers
Manu Sporny: So, this? Allow the digital receipt format to
include domain-specific vocabulary information to support use
cases such as including machine-readable licenses, nutrition and
perishability information, UPC/GS1 identifiers, tax
classification, and other information that can be later used to
obtain access to a service.
Pindar Wong: These are just examples
Timothy Holborn: Some receipt examples are here (for later,
offline review):
https://nrf.com/resources/retail-technology-standards/xml-schemas
Manu Sporny: Response to Adrian - This was meant to be a general
statement on the requirements around data model extensibility.
The use case has been converted to a design criteria and been
rewritten to capture the intent of the original use case.
Topic: Unclassified/Unreviewed use cases
Manu Sporny: I don't think we need to do anything about either
one.
Manu Sporny: The first one is: When a customer intends to make a
payment, it is possible to pick a payment processor trusted by
the merchant as an intermediate proxy for a payment processor not
trusted by the merchant.
Manu Sporny: This requires decentralized clearing which we don't
have in here for v1.
Pindar Wong: Sorry... what's he trying to say... I don't
understand
Timothy Holborn: I understand.
Pindar Wong: OK
Manu Sporny: Response to Michael - This requires a decentralized
clearing mechanism and we don't have that yet, it's a version 2
feature. It's important, we want to do it, we don't have the
technical bandwidth to solve this problem and all of the other
problems.
Pindar Wong: More trust helps ;)
Pindar Wong: Works for me
Dave Longley: +1
Timothy Holborn: +1
Manu Sporny: Next use case: The buyer uses their payment
processor's website to set a spending limit (and/or other
limitations) for a particular merchant or set or merchants.
Later, when the buyer clicks buy on the merchant's website, the
purchase process is completed immediately (assumed consent) if
the offer price is within the spending limit (and/or other
limitations).
Pindar Wong: +1
Manu Sporny: This is a duplicate use case? [scribe assist by
Manu Sporny]
Dave Longley: We may want to specify other limitations, can we
move that into the prior pay-as-you-go token use case? [scribe
assist by Manu Sporny]
Timothy Holborn: Within agree terms.
Pindar Wong: Purchase bomb attack?
Timothy Holborn: Only within agreed terms
Manu Sporny: Response to Dave Longley: This is largely a
duplicate of the pay-as-you-go token use case, the only bit that
we could add to the pay-as-you-go use case is the ("and/or other
limitations") language.
Pindar Wong: For example: very small deltas in offer price by a
dodgy merchant?
Manu Sporny: You can put other limits on it - per purchase, per
month, etc. to protect against purchase bombs. [scribe assist by
Manu Sporny]
Dave Longley: Or you can say up to $10 can be spent at this
merchant, but for any single offer, only up to $1 can be spent,
for instance.
Dave Longley: A variety of parameters can be offered by payment
processors to their users to manage convenience and trust.
Manu Sporny: I modified the pay as you go use case a bit: A buyer
visits a merchant's website and initiates a payment. Their
payment processor presents them with an option to assign a
pay-as-you-go token with a specific spending limit (and/or other
limitations) for future purchases with the merchant. An option is
also presented to require the display of a receipt when a
purchase occurs (and/or other interactions), or to perform the
purchase in the background with no interactive purchase process
required.
Pindar Wong: Thinking
Pindar Wong: Ok that works for me tks!
Manu Sporny: I think we're done. Does anyone think we aren't?
Cheering / celebration.
Topic: Voting on the Use Cases
Manu Sporny: We can clean it up in the wiki and go through
another set of comments -- but I don't think that would be a good
idea at this point because we've discussed them to death.
Manu Sporny: Let's just put them in a document and see if the
community agrees to it; it's not a final document but let's try
to get agreement on it being a solid starting document.
Manu Sporny: The alternative is allowing everyone to vote on
each individual use case, which might be an issue.
Pindar Wong: I prefer a vote on the entire document, and allow
people to note objections for each use case
Pindar Wong: Vote on whole document but not objections
Dave Longley: I think we should allow people to make notes for
each individual use case. So, vote on document, then leave
feedback on individual use cases that can be integrated into next
revision of the document. [scribe assist by Manu Sporny]
Manu Sporny: The vote is a yay or nay for the document and then
there can be comments on each individual use case.
Timothy Holborn: +1
Pindar Wong: +1
Manu Sporny: We can't go through another round of comments
because it will take too long.
Dave Longley: +1
PROPOSAL: There will be a vote on all of the use cases that the
group has revised over the past 3 months with an option to make
additional comments on each individual use case.
Pindar Wong: Good way fwd.
Dave Longley: +1
Manu Sporny: +1
David I. Lehn: +1
Pindar Wong: +1
Timothy Holborn: +1
RESOLUTION: There will be a vote on all of the use cases that the
group has revised over the past 3 months with an option to make
additional comments on each individual use case.
Pindar Wong: I think we're done! :)
Pindar Wong: HURRAY!
Yay!
PROPOSAL: Open a vote by the end of the week on the whether or
not to accept the use case document as the CG's official
position, the vote will be open for 2 weeks from the time the
polls open.
Manu Sporny: +1
Dave Longley: +1
Timothy Holborn: +1
David I. Lehn: +1
Pindar Wong: +1
RESOLUTION: Open a vote by the end of the week on the whether or
not to accept the use case document as the CG's official
position, the vote will be open for 2 weeks from the time the
polls open.
Pindar Wong: Thank you one and all... thanks Tim for staying up
so very late for you.
Dave Longley: Yeah, thanks tim!
Pindar Wong: Cheers! :)
Timothy Holborn: Cheers ;)
Received on Wednesday, 24 September 2014 18:04:39 UTC