Re: Propose vc-examples-registry work item.

Apparently we already have https://github.com/w3c-ccg/vc-examples/

Is there an objection for using this repo for this purpose?

OS

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

> And I think that’s a great idea, Orie – and I am happy to provide “real
> world” examples of my VCs.
>
>
>
> Leonard
>
>
>
> *From: *Orie Steele <orie@transmute.industries>
> *Date: *Wednesday, March 18, 2020 at 10:14 AM
> *To: *Snorre Lothar von Gohren Edwin <snorre@diwala.io>
> *Cc: *Leonard Rosenthol <lrosenth@adobe.com>, "daniel.hardman@evernym.com"
> <daniel.hardman@evernym.com>, "W3C Credentials CG (Public List)" <
> public-credentials@w3.org>
> *Subject: *Re: Propose vc-examples-registry work item.
>
>
>
> To be clear, my proposal is to provide a place for us to show real
> examples of credentials that use the VC Data Model and the DID Core spec.
>
> I'd be open to VCs (or VPs) that don't use DIDs at all.
>
> The goal is to provide real data, that enables a better understanding than
> the examples provided by the VC Data Model examples, which contain DIDs and
> URLs which are not resolvable, and data that is not verifiable.
>
> OS
>
>
>
> On Wed, Mar 18, 2020 at 7:58 AM Snorre Lothar von Gohren Edwin <
> snorre@diwala.io> wrote:
>
> 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: Image removed by sender.]ᐧ
>
>
>
> 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?
>
> *Error! Filename not specified.*ᐧ
>
>
>
> 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%7Cf4eae84176a44a4cb46108d7cb469ed7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201376486882080&sdata=4kzu%2FIawt6KUi%2F5VaLq4r1AdhGLM%2BYGmuVRn1jqSJbI%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%7Cf4eae84176a44a4cb46108d7cb469ed7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201376486892070&sdata=GhxiElgZtLCmtNMx4Mg%2FL51OZFBN%2B6jUFCp9irFClZw%3D&reserved=0>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> [image: Image removed by sender.]
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf4eae84176a44a4cb46108d7cb469ed7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201376486902063&sdata=uYIjwebMxcZGv78ma5fMl2JvftvkQplkGI%2Bvx8r9%2BUY%3D&reserved=0>
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>