Re: Proposed work item: WebKMS

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/

Received on Sunday, 24 November 2019 17:14:20 UTC