RE: VC-HTTP API Use Case for Audit / Notary

Architecturally, I would suggest Auditing is a resource server/service endpoint role (for resource accesses or attempted accesses).  Ditto for authorization servers, VDRs, etc.
IMO Auditing is not a protocol issue.

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image002.jpg@01D7711C.78278D80]



From: Adrian Gropper <agropper@healthurl.com>
Sent: July 3, 2021 4:13 PM
To: W3C Credentials Community Group <public-credentials@w3.org>
Subject: 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