Re: Proposed work item: WebKMS

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.

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