VC-HTTP API Use Case for Audit / Notary

Audit should be in scope as we work on VC-related protocols. A digital
notary provides independent logs of transactions in a
privacy-preserving and cost-effective way.

One use-case with an audit requirement has been suggested for the VC-HTTP
API WG: *A Community Wants to be Audited* at
https://docs.google.com/document/d/1-u0_Ub6feiX6DH3jXFJFjt6n3CwKGpkmC3VISqDkWL4/
and
I'm hoping for some input from our community. This use-case is being
implemented as part of our self-sovereign health record controller (the
Trustee) at https://github.com/HIEofOne/Trustee-Community.

Audit is needed to increase trust in the community that is hosting the
health record controller service. The community's controller source repo is
open on GitHub and it is automatically deployed to a typical app platform.
The running GitHub commit is therefore subject to independent audit
(assuming trust in the app platform) and the auditor can ensure that it is
notified and logs access to an individual patient's authorization policies
as stored in an encrypted data vault. The auditor should not be able to
access the actual policies for liability as well as privacy reasons.

Here's a sequence diagram:
https://static.swimlanes.io/254264d1105161718978178efa024a34.png

The controller's authorization transactions being audited are based on
policies managed by the patient's wallet which the controller can only
read. As is typical of (health) information exchanges, the patient/subject
and their wallet are presumed off-line when VC access authorization
requests are made to the controller. A request could result in access
tokens to multiple VCs each using a different DID for the subject.

I'm wondering if the BIP32 Audit Use Case
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#audits-nm
can be a model for how a verifier could reach out to the auditor for proof
that multiple DIDs are derived from a common key. The auditor would not
have access to any private keys or to the contents of the VCs themselves.

- Adrian

Received on Saturday, 3 July 2021 22:13:40 UTC