Re: Propose vc-examples-registry work item.

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