Audit trails for Issuers and Verifiers

[agropper]

VCs are a special case of generalized processors. Because the processor has data about an RO in the clear, they could use it in unauthorized ways. When a processor creates and issues a VC, it might or might not be as a result of a controller's direction or request. An audit mechanism is needed to mitigate the risk of rogue issuers.

For example, a client, probably the RO or data subject, could request that a log entry be made in a public ledger upon issuance and also included in the VC. The subject and verifier would then be able to audit the issue. This is similar to voting schemes that give the voter a coded receipt that they can look up on a registry to ensure their vote was correctly processed.

[OR13]

I think the specific of audit trails for VCs or custom VCs that provide an audit trail, with anchoring, etc are out of scope for this API.

[agropper]

A comment on the architecture description PR seems relevant to this issue.

[OR13]

won't fix.