Re: Propose vc-examples-registry work item.

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>