Re: Propose vc-examples-registry work item.

>
> 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.