Web Payments Community Group Telecon

Minutes for 2014-07-08

  1. Uncategorized Use Cases
Manu Sporny
Dave Longley
Dave Longley, David I. Lehn, Manu Sporny, Brent Shambaugh, Timothy Holborn
Audio Log
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: 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

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.