- From: <msporny@digitalbazaar.com>
- Date: Fri, 18 Jul 2014 20:44:02 -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-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