<scribe> scribe: manu

Zero Knowledge Proofs and Verifiable Credentials

burn: There is no set agenda, but we need next steps by end of the call.

brent: Ken and I have been working, trying to reconcile the VC data model with what we require in Sovrin for our signature scheme, we think we've put something together that might work using JSON-LD, but in order to better define the pieces, we need some feedback.

Ken: Yes, that's right.
... I have a slide deck and samples that we put together -- show where we're having translation issues.
... If those are helpful, I can provide those.

burn: Link, please?

Brent: Slide 2 - Verifiable Credentials for Sovrin

<burn> Ken: Will send link to the prez after the call

brentz: This is a map (slide 2) of everything we need in the data model
... In order to map the schemas that exist, rather than Sovrin schemas, this setup would allow us to use schemas as they're used on schema.org
... The pieces in between the VC and schema, like credential definition, need to define a canonicalization function... canonicalization function says "this is the schema, these are the elemnts that we're signign, here is how we turn things into flat array and sign flat array"
... What we need is how we definen the credential definition and canonicalization function... if things are primarily JSON-LD, we'd like in between pieces to be JSON-LD... we need input on what we've put together.
... slide 3 - only changes for our protocol - schemas on schema.org, schema needs to exist in immutable form on Sovrin ledger... or on any immutable ledger.
... slide 4 - encoding definitions need to be on immutable ledger
... how do I turn a string into a number? that's the question here - when issuer is determining public keys, they can specify what they're specifying and how they're specifying it.
... encodings are used in canonicalization function... packaging that has each of the attributes that are signed, how they're being encoded, order that they'll be used in the signature.
... mapping between claims and signature in proofs.
... slide 6 - credential definition, public key, canonicalization function, information you need to do that.
... If we can get a solid understanding of how to do this, anything else that we need on proof request/presentation side, we can figure that out.

dlongley: Feedback so far - understand what you're trying to do at a high level - interested in details.
... I think this is going in the right direction

brentz: Good, we think it is as well

Ken: This is somewhat of a departure from what we've been doing in Sovrin... trying to fit into JSON-LD model rather than what we were doing before...

<dlongley> +1 to improvements and interop

Ken: This improves the functionality for the Sovrin community - flexibility of what they can specify, ability to fully support ZKPs.
... Big win if we can pull this off.

Ken shares examples VC using JSON-LD + ZKPs.

brentz: We need to be able to define schema on Sovrin Ledger.
... In the @context, the contexts include terms that are not used later... we've commented out ones not being used in rest of schema... kept ones that are being used... we've changed schema to Sovrin Schema.
... Software will know how to resolve sov:schema: identifier.
... We've defined additional terms, basetype and meta
... We are putting these in Sovrin Meta namespace... text, number, we'd define as base type on Sovrin... anchored immutably on Sovrin Ledger.
... That's the change to @context... starting w/ ID, "schema:3Ddlkj389vfhn2398fh"
... We've kept type as RDF property... we want JSON-LD to be able to link these things together...
... We tried to determine what needs to be immutably on the ledger, and what does not need to be.
... We're keeping RDFs comment... meta schema / domain includes... provide Person schema.
... range includes for base type of text
... meta:sameAs identifier for given name, schema, again.

<burn> manu: we understand what you are trying to get to. understand why you've done it the way you have. looks more complicated than necessary. may be able to simplify

<burn> ... what's on schema.org right now is an RDF vocab. OWL is used to express the vocab. Sovrin needs cryptographic schemas. Different from what schema.org provides, which is semantic schema. Not much overlap between the two.

<burn> ... understand desire to use JSON-LD, but here you actually don't have to if it's simpler for you. A hybrid cleaner solution might be to annotate. GivenName from schema.org, anchored in Sovrin ledger, with annotations.

<burn> ... Not only provides base semantics, but then can have crypto specifics that go along with the vocab.

<burn> ... at a high level I suggest to annotate rather than modifying what's there.

<burn> ... one requirement is to anchor in a ledger, don't quite know how much we have to do yet.

<burn> ... again, looks more complicated than needed. the challenge with suggesting something is I don't know what you need to do the crypto mapping. Some kind of schema id, base type matters. Are those the only things?

brentz: Hopefully as we move forward, we'll be able to undrestand how the bits fit together.
... Canonicalization function is where things start to get pulled together...

<Zakim> manu, you wanted to provide some high level feedback

dlongley: Yes, agree w/ what Manu said - I also feel like the mapping ... it's clear to me that we need to take some version of some schema on schema.org and put it on an immutable ledger... I'm using this locked in time version of schema.org and point to a ledger where you can look that up.
... I'm worried about schema.org being redefined in a way that will probably create a conflict.
... Instead, we may want to define a resolver for Sovrin-style credentials where there is some other property... annotating things - you can effectively describe the same schema on the immutable ledger, and talk about how you can talk about where you can find more.
... That probably sounded like word salad, have a different idea for how this could work... I want to avoid redefining schema.org.
... I'd like it to be schema.org that is locked in time on an immutable ledger.

brentz: That sounds great - one of the things that Ken and I recognized, is that we don't know what we don't know, so annotations sound good.
... Jumping to canonicalization function - we package different elements of schemas that are referred to and put them into an array w/ encodings... canonicalization function, if someone wanted givenName credential, they'd need a canonicalization function that maps base object ...

Ken: Verifiable Credentials data model schema, pulls one thing, something defined already, giving it encoding schema, doing same thing with data/payload and referring to that going through the path... not complicated path, givenName, not quite a root object, text... specify a path, ordering of path, encoding schemes, ZKP proofs based on known order of which objects appear and what their encoding schemes are... take data in payload... encrypted in a way that you

can do ZKPs.

brentz: This would allow us to take any element and map it to signature scheme so that we can selectively disclose everything.

<burn> z/can do/... ... can do/

dlongley: For each credential definition for different issuer, has their own one.

brentz: Multiple issuers can use same canonicalization function.

dlongley: can you mix match canonicalization functions?

<burn> s,z/can do/... can do/,

brentz: Don't know yet.

dlongley: Some properties in credential need to map to one place in array and that needs to be mapped to a number, for given credential, there would be exactly one mapping... seems like these are 1-to-1 mappings.
... if that's the case, it's much simpler. Or use one or more than one in a given order.

brentz: I do believe it's 1-to-1

ken: briefly, you can refer to more than one credential in a presentation. After you got a credential, you can refer to multiple objects within a signed credential and multiple credentials to do your presentations.

<Zakim> dmitriz, you wanted to ask about whether 'canonicalization' is the right term here

dlongley: So, a presentation can have multiple credentials... for each credential, you have one mapping?

dmitriz: I don't know if canonicalization is the right term here... seems more like a projection operation? Seems more like JSON-LD Framing, not just about putting it in a particular order...

Ken: Yes, but you are using two words that don't exist in my vocabulary -- projection and framing.

<dmitriz> no prob, understood

<dmitriz> was mostly asking for my own understanding

manu: framing is probably not the answer here.

dlongley: Yeah, don't know if it is either - brief definition - framing in JSON-LD is to take a graph of information (which can be represented in many different ways - trees, bushes, etc.)... framing allows you to specify an "object by example", create an example shape of JSON, and you can use JSON-LD processor to make a graph conform to a specific shape.
... It also enables you to filter out the bits of the graph you don't care about... if you want specific properties in specific credentials to appear in a specific place, you can use framing.

brentz: The credential definition would have a specific function, proof of correctness, that signature was created correctly... credential definition has become much simpler, can map between graph element and encodings in specific order.
... This is the piece of it, if we can get more concrete on how it ought to be, simple summary of requirements, schemas need to be anchored on immutable ledger, canonicalization function needs to map between elements that are signed, we'd like it to all be linked as it ought to be.

dlongley: Are you anticipating having more complicated nested style credentials?
... I'm looking at packaging thing on screen, base object, terms of use - some sort of path based style... where givenName might appear multiple times in a credential, are you concerned about that? Path format meant to handle that? Properties might show up in more than one place?

Ken: We are absolutely concerned about that.
... We could imagine that we could have a medical record w/ multiple people - nested down in them, given name property - person might be patient, parent of the patient, you are concerned about that path...
... Given name, associated with person, which is associated with patient, etc. It makes a huge difference when organizing data... we hope to take advantage of some schemas in world, allow us to specify exactly the first element, first name is given name, second is full name, third is givenName, based on complicated nested schemas and then do ZKPs on that.

dlongley: Next question - this path format - have you explored using any other path format? JSON Path?
... follow on question - are you trying to make these paths map to a graph or tree structure... do you have a plan for unordered sets of information - always some specific order for sets of information.
... You have talked about lists of people, do they have an order?
... You might be able to use JSON Path for things in order... sets of information, don't know how that's going to work.
... I think it would be easy to solve this for simple flat credentials, concerned about nested credentials, in general.

Ken: We're interested in better pathing mechanisms like JSON Path...
... We do have other problems, how do you handle sets of objects, how do you handle nested schemas... if you look at FHIR - it is a complex thing... JSON-LD graph of data, we need to be able to express those sorts of things... properly reference data out of those models, properly encode them, and then sign them.

dlongley: One of the things I'm wondering about - can we define an algorithm rather than specific mapping - how difficult to do from perspective of selective disclosure.
... Just throwing ideas out there -- you could do mappings fairly easily if the data is flat...

<Zakim> manu, you wanted to think Nathan and I solved this 9 months ago...

dlongley: don't know how this might not work wrt. selective disclosure.

<burn> manu: nathan and I discussed this 9 months ago and solved it then, but we didn't write it down :(

<burn> ... maybe one of the two of us can remember it. The general problem was that we can't just do a flat array.

<burn> ... we were thinking about the dynamic creation of these or having pointers you could dereference. we might not have solved the problem, but our solution was simple. We need to better understand what you need in the crypto. we may end up needing a recursive algo rather than dynamically nested data structures. we probably can't propose anything today. best might be another call to design this out in detail. work backwards from what data structure we want

<burn> ... to end up with. Goal is to make it easier for developers to use.

<mike-lodder> me too

<burn> ... brent, ken, manu, dave should be on a call to work this out. start with the end goal in looks and ease of use, then figure out how to get there. the group needs the last step, not necessarily the in-between work, just to make sure that all the key aspects have been addressed.

<mike-lodder> and mike-lodder

<burn> ... biggest problem is fhir data models

Ken: Yes, would like to do that.
... We knew where we needed to end up and we did it "bottom up", but happy to do it "top down" as well.
... You and Dave's expertise in JSON-LD might help us make progress towards something that is achievable and simpler.

<Zakim> dlongley, you wanted to suggest using JSON-LD flattening on the data and skipping all path resolution might work

Ken: Happy to work towards that.

<mike-lodder> +1 to extra call to iron out details

dlongley: Happy to have another call - can use some tools that might help solve this problem... might be able to do JSON-LD flattening and do some path resolution.

burn: If you would like help from chairs, let us know... if you want to work on this together, work on joint proposal... let us know what help you need.

Ken: We can setup a call between all 4 - get us started in right direction, if we need additional help, we can pull other folks in.

<dmitriz> Ken: I would also like to be on that call.

Ken: I can setup that call.

burn: Do we have an estimated target?

Ken: Would prefer earlier than later...
... Will be spending as much time as necessary...

burn: Proposal that group has to present a week from tomorrow.

Ken: Good goal.

brentz: Thanks to everyone for joining.

Ken: And providing input.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Slide 1/Slide 2/
Succeeded: s/slide 2/slide 3/
Succeeded: s/can do/... can do/
Present: Dan_Burnett Brent_Zundel Ken_Ebert Ganesh_Annan Dave_Longley Manu_Sporny Markus_Sabadello Mike_Lodder Tim_Tibbals Oliver_Terbu Dmitri dmitriz
Found Scribe: manu
Inferring ScribeNick: manu

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)