Re: Propose vc-examples-registry work item.

I have to ask, what will be the difference between this and did:facebook?
I thought the specification tried avoiding these scenarios, or am I wrong?
ᐧ

On Wed, Mar 18, 2020 at 1:01 AM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

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


-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io