W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2014

Web Payments Telecon Minutes for 2014-09-24

From: <msporny@digitalbazaar.com>
Date: Wed, 24 Sep 2014 14:04:14 -0400
Message-Id: <1411581854171.0.2623@zoe>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:39 UTC