Web Payments Telecon Minutes for 2014-07-08

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-07-08/

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-07-08

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0026.html
Topics:
  1. Uncategorized Use Cases
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, David I. Lehn, Manu Sporny, Brent Shambaugh, 
  Timothy Holborn
Audio:
  https://web-payments.org/minutes/2014-07-08/audio.ogg

Dave Longley is scribing.
David I. Lehn: Nope
Manu Sporny:  Any updates?

Topic: Uncategorized Use Cases

Manu Sporny:  Are there any in scope use cases that have come up?
Manu Sporny:  Or are we ready to do just out-of-scope/later use 
  cases?
Brent Shambaugh: E.g. Uncertain Classification?
Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
Manu Sporny:  We don't know where they fit ... the person that 
  submitted the use case either wasnt' clear in what they wanted 
  accomplished or it's something out of left field that doesn't fit 
  into the work ... at least not now
Manu Sporny:  We had a high-level pass of this last week
Dave Longley:  We do need to separate between not in scope for 
  1st iteration and not in scope for web payments in general. 
  [scribe assist by Manu Sporny]
Brent Shambaugh: Could we have a 1st iteration and a 2nd might be 
  nice iteration?
Dave Longley:  Brent, are you saying classify them as 1st and 
  2nd?
Dave Longley:  It's unclear what you mean
Timothy Holborn: That’s a marketing use-case
Brent Shambaugh: Yes, use cases appropriate for the 1st 
  iteration, and use cases for a 2nd (and subsequent) iterations.
Dave Longley:  Let's make a policy category and put some of these 
  there
Brent Shambaugh:  Ok, we've already got the 1st done
Timothy Holborn: I actually think striking them is probably a 
  good idea.  it’s implicit that they’ll be incentive to take-up 
  the standard
Dave Longley:  We're talking about the 2nd and the "never going 
  to be in scope" cases right now
Brent Shambaugh: Okay..thanks Dave Longley
Dave Longley:  If "access" is referring to "use the web" that's 
  implicit
Timothy Holborn: Policy
Dave Longley:  So this is policy

USE CASE: Use Case: Take the change for your $100 bill through a 
  web payment.

Manu Sporny:  Digital cash, change for $100 goes to 2nd+ 
  iteration

USE CASE: When doing a payment, need a way to assure the customer 
  he is his payment service provider and is not subject to phising. 
  Specially problematic in mobile when browser chrome is not 
  available.

Timothy Holborn: You could issue a web-id to the handset?
Timothy Holborn: Rather a x509 cert?
Manu Sporny:  The issue ... the discussion at the paris workshop 
  was it's very difficult to determine the difference between a 
  fake page
Manu Sporny:  And a real one
Timothy Holborn: Yup
Manu Sporny:  It's very easy to spoof
Manu Sporny:  On mobile you have no browser chrome in general 
  even harder
Timothy Holborn: K
Manu Sporny:  Maybe make the mobile phone highlight the border 
  around the window or some hardware-based notification indicating 
  you're talking to your payment provider
Manu Sporny:  And that's out of scope
Timothy Holborn: Understand
Manu Sporny:  We're letting folks like the GSMA figure that out
Timothy Holborn: Difficult one

USE CASE: Payments / digital receipts should be applicable to 
  Encrypted Media Extension authorization to show content.

Manu Sporny:  Chaals wants the same proof of purchase mechanism 
  to be used for EME spec
Manu Sporny:  He wants us to talk to them so the HTML5 specs 
  don't have to adopt a blackbox in the browser

USE CASE: Payment process includes user informed consent 
  requirements about "what they are getting into".

Brent Shambaugh: Getting into?
Brent Shambaugh: Like a disclaimer
Manu Sporny: Yeah, only embedded in the receipt.

USE CASE: Send money in any currency, have the network 
  automatically do currency conversion, give currency at the other 
  end in the receivers native currency.

USE CASE: Market makers acting as a transfer agent (foreign 
  exchange happens automatically)

USE CASE: Transfer money through gateway providers of financial 
  networks.

USE CASE: Knowing through which financial network your 
  transaction will be delivered (you might care?).

Manu Sporny: Ok, so all of these are not for the first iteration.

USE CASE: Electronically originated checks

Timothy Holborn: That’s IOU's
Timothy Holborn: It’s an IOU - an asserted IOU Essentially...
Timothy Holborn: I’d say it’s included in other areas...
Manu Sporny: But not for the first iteration (it's more or less 
  supported by the other use cases that are in scope too)

USE CASE: Knowing what info will be required to supplement a 
  transaction.

Timothy Holborn: So, it’s notification?
Timothy Holborn: “In-order to carry out this transaction you will 
  be required to give us xx information..."
Manu Sporny: Yep, not in scope for first iteration.

USE CASE: Knowing that data minimization principles are followed 
  by systems in a payment chain

USE CASE: Digitally signed contacts that are born and executed 
  digitally.

Timothy Holborn: I’d keep it in scope
Timothy Holborn: Different use case - same tech.,

USE CASE: 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.

Timothy Holborn: I think including explicitly somewhere, the 
  capabilties for digital contracts - v.important
Timothy Holborn: Their is an array of different use cases for it
Timothy Holborn: Technically, yes.  in english - important it’s 
  documented
Timothy Holborn: Binding a person to those concepts?
Timothy Holborn: It’s still a valid usecase
Manu Sporny:  Smart contracts are out of scope but the system 
  should allow them to be part of the system
Timothy Holborn: Agreed.
Brent Shambaugh: +1
Timothy Holborn: I think the scope around e-contracts may be more 
  complex that considered on a high-level
Timothy Holborn: So, including it...

USE CASE: Allow a physical version of a digital receipt that can 
  be verified, perhaps by printing out a QR Code on a slip of paper 
  with some additional information.

Timothy Holborn: Design criteria?
Timothy Holborn: Mind; where’s the data live?

USE CASE: The wallet as an expert system - decide the best mode 
  of operation for the purchase, make wallet providers compete on 
  that metric.

USE CASE: Wallet is synced with loyalty coupons and digital 
  receipts as they are collected. Data is synced to cloud or local 
  wallet seamlessly.

Timothy Holborn: Design Criteria: Wallet data should be separate 
  from wallet provider, data should be owned by the customer.

USE CASE: Where is the wallet, how is it protected, is it stored 
  on the same device as your 2-factor authentication device? 
  Security side-effects of mobile-as-wallet are not 
  straightforward.

Timothy Holborn: It’s a best practice consideration
Timothy Holborn: Which might be put somewhere in documentation, 
  but how it applies to the spec is tangential
Timothy Holborn: I agree.

USE CASE: Prevent corporate man-in-the-middle attacks that are 
  commonly used in corporate environments.

Timothy Holborn: I imagine it mgiht be a design note

USE CASE: Payment systems running on shared devices must be able 
  to determine the payer.

Timothy Holborn: “Best practices” design notes
Timothy Holborn: Agreed.
Timothy Holborn: More about communications.
Timothy Holborn: They’ve been a few communications use-cases
Timothy Holborn: Strike
Timothy Holborn: I think determining the end-user, is a science

USE CASE: Protect privacy when making purchases using geolocation 
  technologies.

Timothy Holborn: I’ve been working on privacy stuff
Timothy Holborn: It’s complicated.
Manu Sporny:  This has to do with do not track stuff, bigger than 
  just web purchases
Timothy Holborn: I say, leave it in for the moment - and perhaps 
  we’d agree that the scope around privacy might be reviewed once 
  we’re ready.

USE CASE: Figure out a way to couple identities together to allow 
  one identity to retrieve access to another identity if the 2nd 
  identity loses their 2FA device.

Brent Shambaugh: With the same level of security?
Timothy Holborn: They’d need to authenticate to their identity.  
  the number of ‘shopfront’ identities may be n
Allow a person to use a second identity to access their first 
  identity if the person loses the ability to use the first 
  identity.
Timothy Holborn: In fact, i imagine they’d be able to set-up 
  multiple identity services if they choose to
Timothy Holborn: N = limitless

USE CASE: A person sets a second identity as a backup for 
  accessing their first identity, should they lose the ability to 
  use the first identity.

Brent Shambaugh: What is an identity to you?
Timothy Holborn: They’ve not lost access if the back-up is 
  available to grant them access
Timothy Holborn: Their is identity and an identity provider
Timothy Holborn: AUTH is supported via the identity provider
Timothy Holborn: I have several domains.
Timothy Holborn: They could all be seperate identity providers 
  for me
Timothy Holborn: I might or might not link them together
Timothy Holborn: (If the LD is public, then the choices about how 
  they’re linked become diminished…)
Timothy Holborn: (Working on the privacy aspect._)

USE CASE: Figure out a way to couple identities together to allow 
  one identity to retrieve access to another identity if the 2nd 
  identity loses their 2FA device.

Timothy Holborn: Seems like a design criteria
Timothy Holborn: Sorry - Use Case: Protect privacy when making 
  purchases using geolocation technologies. - is the specificity of 
  ‘geolocation’ required?  is the use-case actually about 
  protecting privacy

USE CASE: Realtime purchases involving prerequisite reception of 
  funds from international sources (e.g. family).

Timothy Holborn: It’s a card not present transaction?
Manu Sporny:  For example someone in carribbean uses mobile phone 
  and gives source payment address of uncle in NYC and uncle is in 
  kiosk in NYC and makes payment on behalf of person in store in 
  carribbean and person can take item home, too complicated for 
  version 1 but supported
Timothy Holborn: Sounds like a web-payment user-story
Manu Sporny:  Meaning that the proof of transfer/purchase works
Manu Sporny:  You send details between the people
Dave Longley:  More like just a gift purchase.
Timothy Holborn: But i’d imagine that use-case is that the 
  international person providing the funds to the merchant is the 
  purchaser, the person in front of the counter - is the reciever
Brent Shambaugh: Gut feeling: easy with LD
Manu Sporny:  We'll send this on to the mailing list, get 
  feedback, then send onto steering group, etc.
Manu Sporny:  Any other thoughts on the use case stuff, does it 
  seem like a reasonable way to get more consensus?
Timothy Holborn: I’m thinking the ability to include licensing 
  information as part of the reciept is perhaps important
Timothy Holborn: But i’m not sure how that looks yet.
Timothy Holborn: Licensing information may include privacy stuff

USE CASE: A customer purchases access to a service on a vendor'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 vendor can use 
  this machine-readable license to enforce access to the service.

Timothy Holborn: By licensing i’m thinking both something like 
  creative commons, and a privacy styled method
Manu Sporny:  We have license information and how to express it 
  in a payswarm document as well
Timothy Holborn: For data relating to the transactions
Timothy Holborn: But the method doesn’t exist yet to my 
  understanding.
Dave Longley:  It's in a payswarm doc already
Dave Longley:  In the implementation certainly
Timothy Holborn: Awesome
Manu Sporny:  It needs to be refined more
Manu Sporny:  But the beginnings are in there, it's been in there 
  since the beginning
Manu Sporny:  Specifically, the reason we had for expressing 
  licenses was for digital music/video use cases
Timothy Holborn: I remember reviewing that history ;)
Timothy Holborn: Sounds good
Manu Sporny:  The media companies are very interested in 
  expressing rights and responsibilities
Timothy Holborn: With regard to personal information privacy
Manu Sporny:  As a result of purchase
Manu Sporny:  Ok
Timothy Holborn: I’m thinking the license method is perhaps 
  something that can be applied in the same way
Timothy Holborn: So, if their was a creative commons like privacy 
  method; the URI would be described
Manu Sporny:  Yeah, in fact, some of the privacy stuff could be 
  part of the license as well
Timothy Holborn: My GIS Point data is used for securing the 
  transaction only
Manu Sporny:  And Tim, for the license stuff, we had a mechanism 
  in there for just pointing to a CC license
Timothy Holborn: :)
Manu Sporny:  Expressed in cc-rel
Timothy Holborn: Understood.
Manu Sporny:  That's it for the call today, we'll chat again next 
  week
Manu Sporny:  We can discuss what the agenda will be on the 
  mailing list
Manu Sporny:  I think these are the use cases we will push into 
  the steering group
Manu Sporny:  And that will end up being input for what technical 
  work needs to be done, the good news is the vast majority of 
  these cases we have tech for already
Manu Sporny:  There's some refactoring to do a bit
Timothy Holborn: Sounds good
Manu Sporny:  If no one has anything else, that's it for the call 
  today.
Timothy Holborn: Congrats to getting through the use-cases ;)
Timothy Holborn: Bye

Received on Saturday, 19 July 2014 00:44:25 UTC