Re: Propose vc-examples-registry work item.

Sorry if I came across defensive :)

Sounds like it should be possible to construct an example of:
https://www.w3.org/TR/vc-data-model/#example-25-a-verifiable-presentation-that-supports-cl-signatures

where:

`issuer`, `credentialSchema.id`, `credentialSchema.type`,

are all real world / universal resolver dids, and where none of them are
specific to indy ledgers... and also where some / all of them are specific
to indy ledgers...

These are exactly the kind of examples I want to see...

> 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 :)

Both the did-core spec and the vc-data-model spec, are entirely too
vague on the concept of a
https://www.w3.org/TR/vc-data-model/#dfn-verifiable-data-registries, but I
generally agree with you that if a credential requires such a revocation
system, that system needs to be defined... that fact that the system could
be an indy ledger, or could be a database / http api is what allows for
interoperability, and providing an example of each case helps us see that
truly portable / interoperable ZKP VC / VPs are available today.

In a slightly related question, is it the case that a VP of proof
type "AnonCredPresentationProofv1" might wrap a VC of proof type
"Ed25519Signature2018" ?

That's another example I would like to see.

Thanks for all your comments of github issues :)

OS





On Tue, Mar 17, 2020 at 5:57 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Orie:
>
> I wasn't proposing that you change the repo name. I was proposing that we
> answer the question, "Will this effort include a reasonable effort to
> guarantee interop of presentations, or will it neglect them and focus
> largely on VCs?" It seems that you responded defensively, but attack or
> criticism wasn't my goal. I'm sorry if I came across that way. I just want
> to know whether the interop effort will yield any fruit I can use. A focus
> on creds WRT interop largely marginalizes ZKPs, where presentations are
> much more important.
>
> >create ZKP VPs that are interoperable with indy, without using indy
>
> All VC methods, not just ZKP ones or ones from the Indy world, will
> require resolution against a ledger where the issuer's DID lives. Do you
> expect to be interoperable with a JWT-based VC that has an did:eth issuer
> DID, without resolving the did:eth (and thus, "using" Ethereum)? If the
> answer is "no", then why would you want to apply that standard to Indy, and
> why would you think this is an interop-preventing characteristic of ZKP
> creds? (If the answer is "yes", then I really want you to enlighten me
> about how!)
>
> It is entirely possible to create "Indy-style" creds based on CL
> signatures without using a specific Indy ledger. Today, several Indy-based
> ledgers are the basis of such credentials, and tomorrow someone could stand
> up another without any permission or coordination, and the code would
> support it. But you would have to have some ledger that supports credential
> definitions and revocation registries, or else you wouldn't have the
> "verifiable data registry" component that is part of the canonical
> ecosystem diagram for the VC spec.
>
> >Does this example
> https://www.w3.org/TR/vc-data-model/#example-25-a-verifiable-presentation-that-supports-cl-signatures work
> with arbitrary did methods? or only indy did methods, on a specific indy
> ledger instance?
>
> Variations of the example that are identical except for the actual DID
> values could be constructed. There's no reason why someone from any ledger
> ecosystem couldn't generate CL signatures. However, today the identifier
> for the schema (which is a DID in the example) has to come from a ledger
> that lets schemas be published; right now, that's only a few ledgers in the
> Indy family, AFAIK. Changing the schema identifier to a hashlink or similar
> would break that association. The issuer DID in the example comes from the
> same DID method as the schema; I don't think we've ever tested the outcome
> when that's not true, but theoretically there's not a strong reason why it
> couldn't be from any DID method or ledger.
>
> >Are you saying that the only way to demonstrate interoperability with
> Indy ZKP format is to run an indy blockchain node?
>
> Even full-time, heavy clients of Indy don't usually run Indy blockchain
> nodes.
>
> In the same way that you can't correctly issue a credential using did:eth
> without having write access (at some previous setup stage) to a ledger that
> supports the did:eth method, you can't correctly issue a credential using a
> ZKP credential definition without having write access (at some previous
> setup stage) to a ledger that supports them. 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.
>
> On Tue, Mar 17, 2020 at 4:15 PM Orie Steele <orie@transmute.industries>
> wrote:
>
>> I chose the term "vc" because it's the "vc-data-model"
>> https://www.w3.org/TR/vc-data-model/
>>
>> Does indy not use the term "vc spec" to apply to both verifiable
>> credentials and verifiable presentations?
>>
>> Can you suggest a name for the repo that contains data examples for
>> https://www.w3.org/TR/vc-data-model/ that would be more neutral?
>>
>> My goal in suggesting this repo is to make it possible for people to
>> understand what would be needed to create ZKP VPs that are interoperable
>> with indy, without using indy... because that's part of my assumed
>> definition for interoperability.
>>
>> A checked in example would be better than what we have in the https://www.w3.org/TR/vc-data-model/
>> today.
>>
>> Does this example
>> https://www.w3.org/TR/vc-data-model/#example-25-a-verifiable-presentation-that-supports-cl-signatures work
>> with arbitrary did methods? or only indy did methods, on a specific indy
>> ledger instance?
>>
>> As someone less familiar with the Indy ZKP format, is it possible to
>> provide inputs and outputs needed to ensure interoperability, as is the
>> case for JWT / JSON-LD?
>>
>> https://tools.ietf.org/html/rfc7520
>>
>> Are you saying that the only way to demonstrate interoperability with
>> Indy ZKP format is to run an indy blockchain node?
>>
>> OS
>>
>>
>> On Tue, Mar 17, 2020 at 4:29 PM Daniel Hardman <
>> daniel.hardman@evernym.com> wrote:
>>
>>> I don't have an objection, per se. However, I am interested in
>>> clarifying one part of what you proposed.
>>>
>>> >If constructed correctly, we should be able to show how to create a
>>> UniversityDegreeCredential as a ZKP / JWT / LD-Proof... how to present it
>>> to a website using CHAPI... how to present it to another party using
>>> DIDComm, etc...
>>>
>>> This sentence and others that I've seen in github issues recently
>>> reinforce a perception that we present the same credentials that are
>>> issued. The name of the work item "vc-examples-registry" does that, too.
>>>
>>> What I'd like to know is how much we intend to support/encourage
>>> presentation of *presentations* instead of credentials. Since
>>> ZKP-oriented credentials always derive a new credential every time they're
>>> presented, checked-in examples of ZKP credentials won't be good fodder for
>>> presentation interop, except indirectly. Thus the effort at interop won't
>>> benefit the Indy community much unless there's a real effort on the
>>> presentation side.
>>>
>>> On Tue, Mar 17, 2020 at 3:08 PM Orie Steele <orie@transmute.industries>
>>> wrote:
>>>
>>>> Friends,
>>>>
>>>> I'd appreciate a few minutes on the next available call to discuss this
>>>> proposal.
>>>>
>>>> In order to facilitate interop, we often need to agree on the exact
>>>> data that we will be exchanging.
>>>>
>>>> Transmute, Workday and others have been working to define the vc json
>>>> schema specification here: https://github.com/w3c-ccg/vc-json-schemas
>>>>
>>>> And some of us have been checking in example credentials that comply
>>>> with this specification.
>>>>
>>>> However, not every vc data model compliant thing uses json schema, and
>>>> it might be helpful for us to manage a separate work item where we can do
>>>> the following:
>>>>
>>>> 1. Provide hosting for experimental credential formats and their
>>>> machine readable definitions.
>>>> 2. Provide examples of those experimental verifiable credentials.
>>>> 3. Provide examples of VerifiablePresentations (both with and without
>>>> proof) for those verifiable credentials.
>>>> 4. Provide documentation / demonstrations of using the example data in
>>>> this repo, with other work items / software.
>>>>
>>>> For example, here is the well-known did configuration credential:
>>>>
>>>> -
>>>> https://identity.foundation/.well-known/contexts/did-configuration-v0.0#
>>>> -
>>>> https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld
>>>> - https://identity.foundation/.well-known/did-configuration.json
>>>>
>>>> Here are the latest version of the hypothetical certified mill test
>>>> report credential being worked on by Transmute:
>>>>
>>>> -
>>>> https://github.com/w3c-ccg/vc-json-schemas/tree/master/docs/example/cmtr/v0.1
>>>>
>>>> This would also be an excellent place to show examples of ZKP based
>>>> credentials, their definitions, schemas, and proof mechanisms... everything
>>>> needed to be interoperable.
>>>>
>>>> If constructed correctly, we should be able to show how to create a
>>>> UniversityDegreeCredential as a ZKP / JWT / LD-Proof... how to present it
>>>> to a website using CHAPI... how to present it to another party using
>>>> DIDComm, etc...
>>>>
>>>> All in one place.... with the ability to link back to other sources
>>>> such as IETF, HyperLedger, DIF, github organization repos, etc... for
>>>> additional context or information.
>>>>
>>>> The official definitions would live elsewhere, including locations
>>>> outside of the W3C as is the case today.
>>>>
>>>> Any objections?
>>>>
>>>> OS
>>>>
>>>> --
>>>> *ORIE STEELE*
>>>> Chief Technical Officer
>>>> www.transmute.industries
>>>>
>>>> <https://www.transmute.industries>
>>>>
>>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>

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

<https://www.transmute.industries>