W3C home > Mailing lists > Public > public-credentials@w3.org > September 2020

Re: DECO: Liberating Web Data Using Decentralized Oracles for TLS

From: Adrian Gropper <agropper@healthurl.com>
Date: Sat, 5 Sep 2020 20:41:41 -0400
Message-ID: <CANYRo8ikDOHBf5oKtK-dQ+RebMhGhrmHfr74gUDRL3f9+PtWhg@mail.gmail.com>
To: Wayne Chang <wyc@fastmail.fm>
Cc: W3C Credentials CG <public-credentials@w3.org>
Thanks Wayne! This goes to two kinds of SSI applications I'm involved in.

First, it seems to apply to making traditional notaries digital:
https://www.dropbox.com/s/09gz5ihq0rjfncf/Trustee%20Notary%20-%20DHS%20SVIP.pdf?dl=0

Second, it supports the relevance of my hope, that our best practice for VC
Issuers will allow the data subject of the VC to decide whether the VC
should go to them as a Holder, or directly to a Verifier as discussed in
https://lists.w3.org/Archives/Public/public-credentials/2020Aug/0051.html

The introduction of notaries as oracles (using oracle in the sense of the
DECO paper) seems like an ideal catalyst to SSI adoption. It would allow
thousands of major legacy credential issuers that already do TLS to
contribute VCs to a user's wallet or agent trough notarization by a trusted
party. This would give the data subject four options in approaching SSI:

- Use OAuth2 to connect the Verifier directly to the Issuer (requires the
Issuer to support OAuth, client registration hassles, loss of privacy)
- Use UMA2 to connect the Verifier directly to the Issuer (requires the
Issuer to support UMA, some loss of privacy)
- Wait for the Issuer to support VCs (could be a long wait)
- Introduce a notary as oracle (just requires the verifier to trust the
notary if they want the user's business)

- Adrian

On Fri, Sep 4, 2020 at 3:12 PM Wayne Chang <wyc@fastmail.fm> wrote:

> https://arxiv.org/abs/1909.00938
>
>
Received on Sunday, 6 September 2020 00:42:05 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 6 September 2020 00:42:06 UTC