Re: Propose vc-examples-registry work item.

> That's because few (none?) of the other ledger families provide a schema or cred def transaction
>
There is a clear bias there towards DIDs (and VC’s in general) that are based on ledgers of some fashion.

On the other hand, I am working with DIDs (and VCs) that are not connected in any way to a DLT, a scenario that also needs to be interoperable as well.

So let’s be sure to keep our biases where they belong….

Leonard

From: Daniel Hardman <daniel.hardman@evernym.com>
Reply-To: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
Date: Tuesday, March 17, 2020 at 7:54 PM
To: Orie Steele <orie@transmute.industries>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Subject: Re: Propose vc-examples-registry work item.
Resent-From: <public-credentials@w3.org>
Resent-Date: Tuesday, March 17, 2020 at 7:52 PM

Sounds like it should be possible to construct an example...where: `issuer`, `credentialSchema.id`, `credentialSchema.type` are all real world / universal resolver dids, and where none of them are specific to indy ledgers

We could construct such an example today, but it would only work in theory, not in practice. That's because few (none?) of the other ledger families provide a schema or cred def transaction. If we changed so that the data type of those fields supported hashlinks or IPFS paths, then we'd be much more flexible. That particular change would probably be easier to support than many others.

> Similarly, you can't verify a cred where issuer was using did:eth without access to a ledger that supports did:eth, and you can't verify a ZKP presentation from a CL-signed cred without access to a ledger that supports the foundational metadata.

I think you mean that you cannot know if a cred is revoked in a system that supports revocation without a system that supports revocation :)

No. I mean that you cannot know if the credential is revoked or issued without a system that supports the type of issuance assurance that ZKP creds need. ZKP cred issuance trust isn't based on control of a DID alone; it's based on control of a DID *plus* control of a credential definition, even if no revocation is involved.

In a slightly related question, is it the case that a VP of proof type "AnonCredPresentationProofv1" might wrap a VC of proof type "Ed25519Signature2018" ?

I don't think so. Those two proof types are inherently incompatible, since the Ed25519 proof exposes a signature value that cannot be revealed in zero knowledge.