 Okay So next talk is by Liz Steinger on private periodic payments protocol Hi everyone As you know, I'm going to be talking about something called P4 the four P's of private periodic payments protocol. I Think you all can hear me. Okay So a little bit about myself and the company I work for at least authority So the big thing that you should know is that we believe that people have a right to privacy Our mission is to make security easy and it's available to everybody We help others improve their technologies by doing things like security consulting and security audits and we also build technology to we build We also build technical solutions that incorporate these values Like privacy by design empowering users to control their own data and Minimizing access that service providers including ourselves have to user data So to talk about how we are a merchant or a service provider We have something called s4 the simple secure storage service. This is a distributed cloud storage Product basically, but what that really means is that it's built using open source projects and enables client-side encryption So that the users hold the keys to their data not us Also the this also does Sharding of the ciphertext so it gets distributed across multiple places for storage too And the service doesn't operate on access control list basis, but instead works using object capability model or Key-based access. This is similar to how cryptocurrencies work Which I'm sure most of you know and this is a little bit different than having users have usernames and passwords to log into the system So in other words, we don't have any personal account information about the ciphertext that people store with us And this is important you either have the capability or the key to access the data or you don't and we don't So this brings me to the problem that we have run into So we have this wonderful problem We have this wonderful storage product where we don't need to collect information about people in order to provide the actual service itself But to accept payments. We do need to collect personal data at this point in time So in order to process fiat currency payments for subscriptions We need to collect this basic information about them and this means yeah collecting personal data just for the payments Which we thought to ourselves. Hey, maybe we could change this maybe it's possible to do something with privacy where we wouldn't have to Collect any personal data at all So of course You guys all know that be doing privacy right now is a little bit difficult But I do believe that the the idea of expensive for privacy or difficult the lack of convenience in some cases is Relative and I think that this is easily challenged by new technology and people trying to tackle the problem so What we did Was we looked and saw we began researching what the standards are for doing subscription payments with crypto currencies And what we found was quite limiting and didn't meet our needs One current use for zCast shielded transactions is to have people prepay for their subscriptions or just you know Cryptocurrency in general people could prepay and this works for service offerings where you can turn the service off And not have to have any kind of storage or in the interim and that like electricity for example You can just turn it off turn it back on again when people pay again But in our case because we're storing data This wasn't exactly the right solution for us because we need to hold that cypher text And of course you can use smart contracts for managing some aspects of subscriptions But this option with ethereum and other platforms at the moment is not suitable for either the reason that They're not scalable. They're not usable to the end that we need maybe in the future This will be different or in the case of like ethereum. There's a privacy concern there, too and so and then another option is things like pre authorization and That also is a problem because we don't want people to Preauthorize payments to us because it takes away their power to change their minds in the future So if they decide that they want to cancel subscription in the middle of the year or something They should have the ability and if they preauthorize us for numerous payments or something Then that's also a problem. And then of course the idea of you know holding Funds and escrow things like this in other words. We weren't satisfied with what's out there right now So we thought what could we do differently? So We talked about how to make cryptocurrency work for our needs in addition to having the privacy So first we looked at privacy preserving features in cryptocurrency like Zcash shielded transactions We also thought about how we need networked privacy So we looked at Tor and we also thought about how we need to manage Cryptocurrency subscriptions themselves. So the periodicity author the periodicity Problem the pre authorization where we want to make sure that the keys stay with the people and then data standards Just general and cryptocurrency space There's not a whole lot of data standards around how to communicate things like billing period due date late penalty stuff like that That might come along with subscription payments So we had to think about how we could do some data standards for this and of course price volatility You know, we got to manage for the fluctuations right now Especially compared to fiat and during any kind of transition area stage So combined this is what we came up with. These are the layers of the different Tools that we incorporated. So grid sync is the application layer privacy And this is basically just a user interface for Tahoe laughs or Tahoe lafs Tahoe lafs that that project also opensource and this is What is used for the distributed storage? And then Zcash shielded transactions for the financial transaction privacy and then tour for network privacy So here is the actual Step through of how the private periodic payment protocol works So you can see the first step is to initiate the subscription and we do this via the tour browser to make sure that people Are coming to the web page privately so that we don't get their IP address Of course, we have to recommend people don't go to our public site and then go to the tour site because then we could link that together second subscription creation and invite code and this is where Yeah, they they basically at that page They just tell us that they want to start a subscription And so we create a Zcash address to accept the payments and an initial like database entry to just link these things on our side And then we generate what's called a magic wormhole invite code This is another open-source project that we utilize and it's just basically a Way to send the configuration file And the initial invoice information to people and then the third step is the client side subscription Configuration so this happens in the client application grid sync And this makes the connection to via the magic wormhole to receive the initial s4 configuration and the initial invoice that they need to pay And then it updates the configurations locally And kind of interprets the structure of the invoice and can start storing things on the on the local machine as to about their information They're invoicing their subscription information So this way it stays on the client side and it's not actually staying with a centralized service And then fourth they need to make the payment and we need to update that they paid us on our servers So they make the payment to the address that we told them to pay to we watch on the Zcash blockchain to see that That payment was made and then we confirm it and we publish the next invoice And then the fifth step is just the reoccurrence part with between this invoice and the payment And so they their client checks for the next invoice as opposed to us you know kind of feeding that to them and then Yeah, they display the updated invoice information to the to the actual user as opposed to us doing that in a centralized service So that's happening client side So this is what we specced out for an invoice. This is the string and So basically this This is just an example of what it looks like in this example It says the customer is being asked to pay point one zek by a particular date here September 4th for the service least authority s4 and if the payment is made by the given deadline the subscription will be extended by one month which is Some million seconds until October 4th So next steps for us as we're going to Complete the s4 implementation that we're we have of this specification The specification itself is already published on our website. I'll put up the link next We want to get feedback iterate and improve we've got some ideas about How we can extend this further because this was just a basic specification of how you could do this privately So like for example, there's an encrypted memo field in Zcash transactions We could utilize those a little bit more heavily to do any kind of communication maybe even figure out how to put invoice data in that We could also expand on the use of Tahoe laughs because we're having this distributed storage Basically infrastructure we could also use elements of it to to kind of communicate in a private manner to the end users about their subscription status We also think that it could be cool to Work with other wallets that are out there and you know kind of build in this kind of subscription management stuff into wallets And then also create merchant payment payment framework So it makes it even easier for merchants to handle subscription payments in a private Privacy preserving way so yeah just in general hope that other people are inspired by this work steal the ideas not steal Open source, but you know be inspired by the work to do something similar To keep privacy in mind for and doing more payment type stuff with cryptocurrencies That fit some of the more creative business models that are out there already So here's the links that I talked about on our blog you can see the You know short post about it along with download the specification It's not too bad of a read, but it talks about the privacy properties of the decisions that we've made Some of the trade-offs and stuff like that that we have to make in the interim And also it's got even more detailed ideas about future work that could be done And then also another company did a tech a GDPR compliance assessment basically of this whole Specification looking at you know how this kind of works with GDPR And that's also been published and that's available online also and so that's what that second link is and then of course the contributors from my team and the Zcash team and All these people who make the wonderful open-source projects that go into this stuff So that's it, but I guess I'll leave this up Any questions Very interesting seems like a well thought-out solution You by not storing any customer data. You apply you comply with the GDPR really well How do you manage a regulatory risk around? I'd like there is one exception there Yeah, I'd like to hear about that and then my question is how do you manage a regulatory risk on the other side? where you have requirements to know your customer and Concerns about the transparency of payments and being able to respond to subpoenas Yeah, so those are some other issues that we're going to be looking further into in the future I have some vague ideas of some of those things, but I'll start with the GDPR part So yeah, basically the the compliance the compliance aspect of it is that we're not collecting any personal information At least not any that I mean there's like little like little little little like crumbs of information because no matter how much we try to like Not collect any information there or it could be crumbs somewhere else That then people could correlate so we tried really hard to get far as far close to anonymity as we could realistically But yeah, so the encrypted data so so that has nothing to do actually with the payment protocol that itself is great in terms of GDPR compliance because there's no personal data But in terms of the fact that we're doing we're storing encrypted data GDPR, I mean right now. I guess the stance is that encryption isn't quite enough I don't know there's lawyers that can talk to you in more detail about why and there's all kinds of arguments But that the idea that eventually that crypto could be broken And so but then again, we're not the only ones with that problem The whole world has to deal with that problem. So hopefully we'll see some Good response that in the future, but I also think that there's also new technology developments that can help that problem Yeah, I mean I haven't talked to a lawyer about the subpoena thing yet, but I guess we would have nothing to give them That's it in terms of like know your customer as far as again not a tax lawyer But the only thing that I've stumbled across so far is the VAT problem that we might run into that We can't prove that because we're a German company So we have to do the whole VAT thing with our customers and so we can't because we don't know where they live We can't prove that they don't live in Europe so that we shouldn't have to pay VAT on them So I guess it would just be a cost, but it's not illegal As far as I know But that would be the next cool thing would be to shop this around to more Really knowledgeable lawyers if there's any here talk to me and just get more kind of assessment on those problems And maybe publish some more blog posts about like Yeah, okay, if you have no personal data and you're doing this kind of service then it's cool. You don't have to worry about all these compliance things Yeah, actually my first question was exactly about that whether you're compliant with the mld4 and mld5 8 centimeter laundry directive But my second question is Like in terms of psd2 It looks like you're a bit falling into like payment initiation services Like do you look at from that perspective that you actually need to have a license They're forming such a services and like where do you stand in terms of that? Well, I'd have to talk to Again an expert on that aspect of it. It sounds like you even know a little bit more of the names of these things than I do But I mean we're not For us we're just except it's just another way to accept payments for our service So at this point in time if we were to implement this for our s4 Product we wouldn't be doing this for other people in terms of like moving money for others We'd be just accepting payments for ourselves. So I would imagine that that would Not make us any kind of like financial platform Because we're just doing it for ourselves. But again, um, we'll see We have it like half implemented Um, and also we would launch this on like a small scale I mean the amount of people that would pay with zcash shielded transactions over tour For our s4 service is probably not hundreds of thousands of people And so, um, you know, I'm imagining that we can just talk to regulators and And people and stuff and try to figure out like what the solution is for this But um, yeah, and in terms of like money laundering and know your customer I think that most that applies to like financial institutions, but Yeah, if you know lawyers Or a tax accountant tax attorneys things like that that want to come talk to me about this I would love to talk to them and work up with people to do a deeper analysis and have better answers So I'm application developer and if I would like to integrate it As information available on on the link or do I have to set up everything myself or how would that work? Yeah, so I mean we just spec this out for ourselves We also we share like I said the thought process the analysis of what we did and why we did it So right now and then we're doing the implementation ourselves the code will all be open source But if you want to tailor it to a particular different application then you would have to do some work yourself It's not like a One button solution or something All right, let's sing those speaker again. Thank you