Re: Proposed work item: WebKMS

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.

Adrian

On Sun, Nov 24, 2019 at 11:31 AM Anders Rundgren <
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/