- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 25 Nov 2019 04:44:33 +0100
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <cd9eb265-a984-9140-bf91-e333b7fa3743@gmail.com>
Hi Adrian, I totally understand your objectives but I also try to create stuff that actually can be deployed now. Security is essentially binary. Either you managed open that door or you didn't. Privacy OTOH is more like "50 shades of gray". As far as I know, OAuth2 is not really a privacy protocol but a scheme for authorizing "other" parties accessing your personal data stored at a service provider like a social network, hospital or bank. This means that you must "trust" the the "other" party in some way. The Open Banking folks therefore specified OAuth2 for enabling TTPs like lending services access to your financial data. I don't see that payments necessarily benefit from this model since merchants only need to get paid. This is why I started this project which actually is in a [sort of] "launch state" after only 40 calendar days of intensive "hacking". Yes, I'm indeed a bit excited :-) The payment industry is not very much into privacy. W3C's counterpart to my wallet [*] is giving merchants or the merchant's agent the payer's account number. There are no references to OAuth2 there either which is why I conclude that this activity is abandoned. Anyway, the Open Banking Wallet is indeed a "privacy by design" project but it doesn't go as far as you mandate. IMHO, digital cash is a more workable way for obtaining 100% privacy. This is however, another area of expertize. There you still have AML (Anti Money Laundering) and tax evasion issues to bother with making 100% privacy more or less impossible anyway. I still have to figure out how to add digital receipts. Yes, the payment industry haven't managed fixing this "tiny" detail either. Here there are considerable privacy issues. Going back to OAuth2 it was designed for "thin" clients like browsers connected to services like Facebook. The Open Banking Wallet is (definition-wise) a "fat" client and that turns things up-side-down, and IMO in a good way although some die hard purists claim that "This is not the open Web". A gazillion of Android/iOS apps show that this is more of an academic view than the reality. The goal is creating a standardized Wallet App making the download/install issue marginal. If this is not accomplished, it is FAIL anyway. I note that we are approximately of the same age. It is cool that some people continue with engineering in spite of living in a world where you are supposed to retire in your 40'ties! Best regards, Anders Rundgren *] https://w3c.github.io/payment-method-credit-transfer On 2019-11-25 00:59, Adrian Gropper wrote: > Hi Anders, > > Thank you for helping me understand the payment privacy engineering issues. I've still got a ways to go :-( > > It might help us converge on terminology if I explain my two driving principles (for the privacy engineering) are: (1) adoption and (2) privacy = nobody learns anything about the transaction except Alice or her agent. > > My definition of a *wallet is an edge agent* for Alice that has KMS features and can store multiple credentials such as bank relationships or other service provider as resource server relationships. I want the bank or resource server to have a very obvious and proven adoption issue like OAuth2. I'm not sure what tech out there matches OAuth2 in market penetration. I can think of lots of ways OAuth2 can and will be improved to drive adoption even more. For (2a) privacy, I expect the merchant to interact with Alice's agent _before_ ever learning anything about the transaction, including who might be Alice's bank or other resource server. I also expect (2b) that the merchant learns nothing about Alice that can be correlated with other transactions or merchants unless Alice chooses to share that information for some other reason. > > That leaves (2c) where the service provider (bank, resource server, IdP) learns that Alice made a transaction with the merchant at some specific time. OAuth2 and UMA 2 clearly fail this because the bank communicates directly with the merchant. I'm not sure how the various payment processing standards deal with this problem. > > Adrian > > On Sun, Nov 24, 2019 at 3:13 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > On 2019-11-24 20:40, Adrian Gropper wrote: > > Here would be one possible analysis of Anders' open banking flow as mapped into the OAuth terminology. (That does not mean we also have to use the OAuth2 or UMA 2.0 protocols as they are today). > > Hi Adrian, > > The core problem with Open Banking for payments is that it there is no Wallet. This recent 1-minute presentation by the head of UK Open Banking shows some of the issues: > https://www.youtube.com/watch?v=SXiRhCAYRCE > > Note that you select bank in the *Merchant's* application! That's *way* below the standards set by Apple & friends. > > Converting payments to "resources" which the Open Banking folks did, is IMO not an entirely obvious idea. Payments are rather transactional events. > > This is at least what the Open Banking Wallet builds on. No REST, no OAuth, just a very souped-up EMV [*], where the card number has been replaced by a non-personal service URL which also is the foundation the dis-intermediation. > > Regards, > Anders > > *] EMV is featured in billions of payment cards so I did certainly not invent everything. > > > > > Merchant - Requesting Party (RqP) > > Wallet / Agent - Authorization Server (AS) > > Bank - Resource Server (RS) > > > > Registration Phase: User Alice registers with a RS (bank) that she chooses because they offer a standard open protocol. > > > > Transaction Phase: > > > > 1. RqP presents a data access (payment) request to Alice's AS > > 2. AS gives the RqP's client a capability that they can use at some RS (Alice's account number is encrypted) > > 3. The RqP client presents the capability and accesses the resource (payment) > > > > The major privacy problem I see is in Transaction Phase 1 where Alice shares an AS endpoint with the merchant that merchants could cross-correlate. Possible mitigations include: > > (a) a regulation that forbids the merchant from sharing or even storing the endpoint > > (b) a tumbler service operated by an intermediary trusted by Alice like Apple, VPN, or Tor > > > > Adrian > > > > On Sun, Nov 24, 2019 at 12:57 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote: > > > > On 2019-11-24 18:35, Adrian Gropper wrote: > > > Open banking APIs were a feature of the day. I did not sense the standards tension Anders feels but I am probably oblivious to the core issues or politics. > > > > Payments is 80% about politics and 20% about technology. > > > > This slide may be of interest for a privacy engineer: > > https://cyberphone.github.io/doc/payments/open-banking-dual-mode-end-to-end-security-simplified.pdf > > I'm currently creating a video presentation because this effort represent 10 000 hours of dedicated work. > > > > The W3C folks only knows the lingo with "disruption", "fintechs", "SCA", "consents" etc. > > Their actual take on the matter failed pretty immediately since they didn't understand that Open Banking primarily is a security architecture which is outside of their (self-inflicted) mandate. > > OTOH, the Open Banking folks didn't realize that other systems out there use another security architecture which actually is better. > > > > Solution: Keep the Open Banking APIs but permit another security architecture. Imagine, claiming that OAuth2 is not the answer [*] to everything! Shouldn't there be capital punishment for that? :-) > > > > Anders > > *] https://en.m.wikipedia.org/wiki/Law_of_the_instrument > > > > > > > > My sense was that the (small value) payments processors are stuck between their customers wanting "personalization" and the customers' customers (you and me) increasingly wanting pseudonymity if not outright anonymity. I see Apple trying to navigate this balance. I don't understand the payments standards well enough to speak to them. > > > > > > From my privacy engineer perspective and coming back to Open Banking APIs, there's an interesting development in the recent ACCESS Act that looks beyond the current GDPR or HIPAA approach to an agent-driven regulatory system. Here's my short analysis https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-way-to-a-post-hipaa-world/ This is the future I'm looking for. > > > > > > Adrian > > > > > > On Sun, Nov 24, 2019 at 12:15 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>>> wrote: > > > > > > On 2019-11-24 17:44, Adrian Gropper wrote: > > > > I presented DID and VC at a payment handlers symposium organized by W3C in Wall Street last week. The W3C organizers loved the discussion and I met a few of the folks in the audience during the day. > > > > > > > > I think it's very important to reconcile the work of W3C on payments and identifiers. Please let me know if I can help. > > > > > > The W3C payment WG have been running for 5 years without succeeding creating a secure AND convenient on-line payment system. > > > Well, it wasn't in the "plan" but the market doesn't care about what exactly is in the plan and what's not; it craves for results. > > > > > > Now they are betting on SRC while the market (including Apple and Google) already have solved the issues SRC is supposed to fix and in a much better way as well. > > > The major reason for dealing with SRC seems to be for keeping high-profile members which also is of no interest to the market. > > > > > > Anyway, PaymentRequest for Android is actually quite good although it is a proprietary Google solution. Life goes on although not exactly how it once was envisioned :-) > > > > > > Personally I'm betting on Open Banking APIs but with a twist: Instead of supporting TTPs (aka fintechs), I'm trying to dis-intermediate them. This also includes card networks and big tech providers. > > > > > > Anders > > > > > > > > > > > > > > Adrian > > > > > > > > On Sun, Nov 24, 2019 at 11:31 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>>>> wrote: > > > > > > > > Hi Manu, > > > > Thanx for the prompt answer. From: > > > > https://w3c-ccg.github.io/credential-handler-api/ > > > > I extracted the following line: > > > > > > > > "This specification does not address how software built with > > > > operating-system specific mechanisms (e.g., "native mobile apps") > > > > handle credential requests and credential storage" > > > > > > > > Your buddies in the W3C Payment WG stubbornly continue with Web based Payment Handlers although all payment providers I know of put their muscles behind native apps. > > > > The PR/Android and PR/iOS is all that was needed, and it is a deal done. > > > > > > > > https://github.com/cyberphone/doc/blob/gh-pages/payments/paymenthandler.md#the-w3c-paymenthandler > > > > > > > > WebAuth as a solution for payments also seem like a unlikely win. > > > > > > > > Pardon, me for interfering, I will remain silent now :-) > > > > > > > > Anders > > > > > > > > On 2019-11-24 16:27, Manu Sporny wrote: > > > > > On 11/24/19 1:23 AM, Anders Rundgren wrote: > > > > >> Hi Manu, From the ZCAP-LD draft: > > > > >> > > > > >> "Web-based applications could provide choice in Key Management > > > > >> Systems -- potentially allowing customers to bring their own Key > > > > >> Management Systems with them just as they bring their own devices > > > > >> today" > > > > >> > > > > >> Wouldn't it be logical to have KMSes in these devices as well? > > > > > > > > > > Yes, either in the devices (where the WebKMS driver is WebAuthn) or > > > > > using the device's keys to access a remote HSM (where the WebKMS driver > > > > > is something like AWS Cloud HSM). > > > > > > > > > > All the pieces are there today... mobile phones do have HSMs that are > > > > > accessible via native applications and soon to be broadly accessible via > > > > > WebAuthn. > > > > > > > > > >> I may [surely] be biased but this is at least what my 10Y+(!) > > > > >> SKS/KeyGen2 project builds on. The (ab)use of W3C's PaymentRequest > > > > >> made it pretty cool as well :-) > > > > >> https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf > > > > > > > > > > Yes, and this is why the Credential Handler API (CHAPI) is designed the > > > > > way it is and supports not only sending Verifiable Credentials through > > > > > CHAPI, but ZCAPs as well. CHAPI was built from years of hard won > > > > > knowledge gained (and mistakes made) during the creation of Payment > > > > > Request and Payment Handler in the Web Payments WG. > > > > > > > > > >> The use-case you mention like car keys are very interesting but I > > > > >> can't imagine that car keys would be stored anywhere but in client > > > > >> devices. Now, how do you get such keys? In my world through > > > > >> (non-standard) authentication to a service provider. I.e. I (FWIW) > > > > >> do not see that an end-user would ever talk directly to a cloud-HSM, > > > > >> that's reserved for service providers. > > > > > > > > > > Yes, keys can be on client devices, and they can also exist in the > > > > > cloud, and it's up to the application to determine which keys will be > > > > > used to do what. > > > > > > > > > > WebKMS provides the added flexibility of being able to lose your phone > > > > > and all of your phone HSM keys, but not have to rotate out your signing > > > > > keys, which exist in the cloud HSM. WebKMS isn't really meant to be > > > > > accessed directly from the Web, but will most likely sit behind an > > > > > agent/digital wallet of some kind. > > > > > > > > > > To summarize, these scenarios are possible via WebKMS: > > > > > > > > > > * Local HSM only > > > > > * Cloud HSM only > > > > > * Local HSM that authzs to Cloud HSM > > > > > * Local HSM that authzs to shared Cloud HSM (multisig) > > > > > > > > > > ... and the benefit of WebKMS is that the same operations are possible > > > > > via a unified API for the four scenarios above. Clearly, lots of > > > > > discussion needs to happen, and this isn't as fundamental as VCs and > > > > > DIDs... but if folks want to do key management in an interoperable way, > > > > > WebKMS is one possible way forward. > > > > > > > > > > -- manu > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Adrian Gropper MD > > > > > > > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > > > > HELP us fight for the right to control personal health data. > > > > DONATE: https://patientprivacyrights.org/donate-3/ > > > > > > > > > > > > > > > -- > > > > > > Adrian Gropper MD > > > > > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > > > HELP us fight for the right to control personal health data. > > > DONATE: https://patientprivacyrights.org/donate-3/ > > > > > > > > > > -- > > > > Adrian Gropper MD > > > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > > HELP us fight for the right to control personal health data. > > DONATE: https://patientprivacyrights.org/donate-3/ > > > > > -- > > Adrian Gropper MD > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > HELP us fight for the right to control personal health data. > DONATE: https://patientprivacyrights.org/donate-3/
Received on Monday, 25 November 2019 03:44:44 UTC