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?
ᐧ

On Wed, Mar 18, 2020 at 1:33 PM Leonard Rosenthol <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>
> *Date: *Wednesday, March 18, 2020 at 7:06 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 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?
>
> [image: Image removed by sender.]ᐧ
>
>
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.diwala.io%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cd1c1201b971a4e2a60f808d7cb2c55f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201263637612630&sdata=z6PjEIAbrQ6cmS%2Fbanec8TMprbpR%2F%2Fp0omynXBzXvn0%3D&reserved=0>
>


-- 

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