Re: Propose vc-examples-registry work item.

The problem you describe below is not a technical problem but an educational one.  The end user is confused about they have (or don’t have) and how they can/can’t use it.  I would hope that as DID moves forward, in all of its aspects, that we will work on our marketing & educational strategies as well.

But AFAIC, DIDs are DIDs.  Just as a Verifiable Credential can exist and be perfectly valid without any information about a person/organization – basically its original goal of a “Claim”.

Leonard

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Date: Wednesday, March 18, 2020 at 8:58 AM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>, Orie Steele <orie@transmute.industries>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Subject: Re: Propose vc-examples-registry work item.

I agree, but then I guess that rubric of what does the different did methods offer becomes really important.
Because if someone goes and creates a did:facebokwhatever, and brag about being decentralized identifier.
The user can be confused and use it because the brag about beeing free.
And when that user goes and do something bad somewhere, did:facebookwhatever will delete that did, change ownership or something that makes that did impossible to use in any case. Because they can.

Using a proper DLT, makes that impossible, unless the key handling is bad.

So what is your thoughts on "branding" this did in comparison to did:ethr and did:btcr that is truely decentralized?
Will you inform the user about this?
Or do you think this is not your education fight to bear?
[Image removed by sender.]ᐧ

On Wed, Mar 18, 2020 at 1:33 PM Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
> I have to ask, what will be the difference between this and did:facebook?
>
I guess the answer is NOTHING.   And that’s a good thing.

As I read and understand the DID spec, it’s actually trying to *allow* both “did:facebook” and “did:someones-dlt”.  They would both be valid DIDs and could be used interoperably.   And that’s a VERY GOOD thing.

Leonard

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io<mailto:snorre@diwala.io>>
Date: Wednesday, March 18, 2020 at 7:06 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: "daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>" <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>, Orie Steele <orie@transmute.industries>, "W3C Credentials CG (Public List)" <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: 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?
Error! Filename not specified.ᐧ

On Wed, Mar 18, 2020 at 1:01 AM Leonard Rosenthol <lrosenth@adobe.com<mailto: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<mailto:daniel.hardman@evernym.com>>
Reply-To: "daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>" <daniel.hardman@evernym.com<mailto: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<mailto:public-credentials@w3.org>>
Subject: Re: Propose vc-examples-registry work item.
Resent-From: <public-credentials@w3.org<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.diwala.io%2F&data=02%7C01%7Clrosenth%40adobe.com%7C41469d2eaaa647328eb408d7cb3c021d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201330908915268&sdata=nL3hGSR6ZYssQ2VTQm1fdhCsA0GbaajqNtSMZjT1txU%3D&reserved=0>


--
Snorre Lothar von Gohren Edwin
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.diwala.io%2F&data=02%7C01%7Clrosenth%40adobe.com%7C41469d2eaaa647328eb408d7cb3c021d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201330908925263&sdata=DyvnZFkH7aK97l9%2ByivkLJmeAmMKE2y1ES%2FCLvXf5Pc%3D&reserved=0>