- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sat, 5 Sep 2020 20:41:41 -0400
- To: Wayne Chang <wyc@fastmail.fm>
- Cc: W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CANYRo8ikDOHBf5oKtK-dQ+RebMhGhrmHfr74gUDRL3f9+PtWhg@mail.gmail.com>
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