W3C

- DRAFT -

Verifiable Claims Working Group

11 Jul 2017

Agenda

See also: IRC log

Attendees

Present
Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg, Matt_Larson, Richard_Varn, Sean_Bohan, Charles_Engelke
Regrets
Liam
Chair
DanB, MattS, RichardV
Scribe
dlongley

Contents


<liam> ]I will try & monitor IRC, but will be entirely without network access next Tuesday (starting later today or early tomorrow for approx. 10 days) ]

<burn> Thanks Liam. If you have any updated/new information on hotel room availability for TPAC, it would be great if you could provide it in the chat at some point after we begin.

Agenda review, Introductions and Reintroductions

<ChristopherA> Ok, got webex & irccloud on iPhone working together. Hopefully can help me when traveling to be able to participate better.

<ChristopherA> I have a brief report from this week's hackathon re Verifiable Claims

<burn> okay. We can add that after Intros

<liam> [I asked about rooms but didn't get a response yet]

<scribe> scribe: dlongley

<stonematt> agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Jul/0002.html

burn: Christopher Allen will be giving us an update on VC hackathon.

nage: My name is Nathan George. Software architect with Evernym. We do distributed identity, specifically project where code is located at Hyperledger Indy under Linux Foundation. We use the code base to build Sovrin. It's intended to be a global public utility for identity where folks own their own cryptographic identity and no one can take it away. People can interact with each other using it, one way is using VC. We're working to make our stuff

compatible with VC here. We want people to be able to use CL crypto to do selective disclosure, etc.

WG Face to Face meeting @ TPAC (https://www.w3.org/2017/11/TPAC/Overview.html#details)

burn: We'll have a F2F meeting this fall for TPAC. This is just a reminder to register and get a hotel room, fills up fast. Not sure what's available right now, haven't looked recently. Anyone have success/failure recently?

none

burn: If you haven't done it, please do so.

<amigus> on which day(s) are we to meet at TPAC?

this week's hackathon re VC

<ChristopherA> https://github.com/WebOfTrustInfo/btcr-hackathon/blob/master/docs/verifiable-claim-did.md

<nage> links to items from my introduction https://github.com/hyperledger/indy-sdk and https://sovrin.org/

ChristopherA: So basically, the hackathon is associated with a number of members of RWoT community. Trying to get DIDs to work with VCs. Which are basically decentralized identifiers that can be hosted on blockchains. In this particular case bitcoin. Despite documentation and a number of having history with this stuff we're finding it hard. Everything ranging from us saying we'll send this picture here. What is the whole kind of structure by which you

receive a VC, you then have to go through some kind of process to look at the VC information, verify it locally and then go out onto the blockchain to look for other things to let you verify the keys and such. We're finding lots of little questions that with good examples we'd be able to do better. We're having challenges because things like the playground ... one of the issues, the VC playground, things that are questionable from a crypto sense and a VC

sense.
...: One of the issues from the spec is from the VC spec, we're confused about roles. Good news is that we have live DIDs and DDOs that are on my github. Right now it doesn't verify because the playground crypto has some problems. But hopefully by the end of the week we'll have a real start at an example on self-claim verifiable claim.
... Hopefully a RWoT example will be up by the end of the week. If anyone's interested in participating it's not too late, lots of issues related to censorship resistance, revocation, scaling issues, so on. I can also schedule a call to talk with people at 10 PT to talk details.

Discuss FPWD for Data Model doc--what issues are blocking finalizing the FPWD

PR 56: Terminology poll report

<burn> https://lists.w3.org/Archives/Public/public-vc-wg/2017Jul/0000.html

burn: So we're still working on terminology.
... I was going to ask Manu to summarize but he can't be here today.
... A quick reminder that first the poll results are not a binding vote. They are just intended to be information for the group and for the chairs.
... The first result, we believe that there's a clear winner: Issuer. That was a clear result in all rounds.
... The second role, we believe wasn't quite as clear cut. The result "Holder" is the one that stayed ahead all throughout the instant runoff process. We believe that's reasonable as the term to use initially in the FPWD.
... We actually think the third result was unclear, people have been polarized. The word "Verifier" itself has some problems in English. Whether we're one who requests verification or one who provides it.
... The chairs suspect some of the problems we've had in the discussion and in the poll might indicate that the group has not adequately determined and separated all of the roles involved in this third term. The chairs propose we use a temporary term. Our suggestion is that we combine the two top results "Inspector-Verifier" and note that this name is still under discussion. We expect further discussion post FPWD.
... This is probably a surprise for some people, we just think it will cause more trouble to pick one of these two.

<ChristopherA> +1

burn: I'll open up the discussion now.
... I'll go ahead at the end and make that as a formal proposal and do +1/-1 decision.

stonematt: Generally echoing your intro, I think you did a nice overview. We were a bit surprised, we watched the results come in, where this was the one where there was such a close call. If you notice round one inspector and verifier got equal votes. Almost no one who voted for one voted for the other highly as the subsequent rounds came in. We took that to mean more discussion is needed.
... We spent most of the time on the "Holder" role not the "Inspector/Verifier" so was interesting.

ChristopherA: I just wanted to concur that I like the temporary and explicitly temporary thing for this. My gut here is ... after having a variety of calls walking through VC and it gets a little more complex outside of the data model. There are various inspection and verification things that happen, with key existence, etc.
... There's a potential problem with the holder of the keys, and the relationship with the issuer isn't always that obvious.

<stonematt> +1 on insight from implementors :)

ChristopherA: I'd love to have an agenda item for splitting up the roles a bit more after we get FPWD out.

burn: Yes, everything is open for discussion still and I encourage people to submit issues to github. We will discuss them.

varn: Echoing what Christopher is saying, that's helping me get to the point where we can do FPWD with the compound term. We need to have sharper definition of roles. There are some others out there too. We have been overlapping the task and the object being handled with the role and we need the data model to get sharper with the various parts and combinations in different scenarios. We haven't deal fully with the agency issues. A verifier can be an

agent, others will be acting on behalf of holders. We have a lot of work to do, but we're just getting a placeholder for a name. Shouldn't cause consternation.

nage: I wanted to support what Christopher said. As we've been diving into implementations and clarity between the roles becomes more clear. I'm kind of happy with the composite role (Inspector-Verifier) right now. So I think these temporary terms will serve us well to describe the issue and getting into the actual interactions that occur using the items in the data model. That will get us through the next round of the data model paper and the

descriptions and we can talk about how they'll be applied so roles become more clear moving forward.

burn: Any other comments before the formal proposal?

none

<burn> PROPOSED: For the FPWD we will use the following terms: for the first role Issuer, the second role Holder, and the third role Inspector-Verifier, with a note explaining that the third term is hyphenated because of a lack of consensus, to be resolved in future discussion.

<nage> +1

+1

<varn> +1

<cwebber2> +1

<JohnTib> +1

<Colleen> +1

<gkellogg> +1

<amigus> +1

<Charles_Engelke> +1

<stonematt> +1 from stone

<ChristopherA> +1

<TallTed> +1

<MattLarson> +1

RESOLUTION: For the FPWD we will use the following terms: for the first role Issuer, the second role Holder, and the third role Inspector-Verifier, with a note explaining that the third term is hyphenated because of a lack of consensus, to be resolved in future discussion.

burn: Thank you, everyone.

<stonematt> yay!

Readiness for Data Model FPWD vote

burn: Next item is "How ready are we to vote to publish FPWD"?
... Obviously the editors need to apply the decision we just made. It is possible that the group can agree to publish a FPWD after we apply the changes. Anything else missing that anyone else believes must be addressed before FPWD?

<ChristopherA> W+

ChristopherA: The only minor thing that I'd really like to see is... a lot of time these documents are distributed around separate from issues. I'd like to see the names and numbers of roles are being considered. I want to make sure the doc lists the issues. Want us to be clear that those issues are open.

<ChristopherA> No, I'm ok with intent, "perfect is enemy of good"

burn: My one comment on that is that ... that sounds great. I'm a little concerned that if we miss one that you'll be unhappy and went ahead and published. I'm perfectly fine with an intent for the editors to capture what they believe are the names/numbers of roles that have been proposed and are still being discussed. As long as their is an honest attempt or do you want to see that change done and then do a vote next week?
... Any other questions or comments then?

<burn> PROPOSED: After updating the FPWD to incorporate the terminology decision above and Christopher's request, the group approves publication of the Data Model specification as a FPWD.

<burn> PROPOSED: After updating the Data Model document to incorporate the terminology decision above and Christopher's request, the group approves publication of the Data Model specification as a FPWD.

<stonematt> +1

<gkellogg> +1

<TallTed> +1

+1

<Colleen> +1

<JohnTib> +1

<MattLarson> +1

<ChristopherA> +1

<cwebber2> +1

<nage> +1

<Charles_Engelke> +1

<varn> +1

<amigus> +1

RESOLUTION: After updating the Data Model document to incorporate the terminology decision above and Christopher's request, the group approves publication of the Data Model specification as a FPWD.

<ChristopherA> "Hums"

Issues related to Revocation and Validation

<burn> https://github.com/w3c/vc-data-model/issues/9 & https://github.com/w3c/vc-data-model/issues/35

<stonematt> issues, not PRz

burn: These were the issues that members expressed the most interest in discussion.
... So, where do we need to go on these issues?

stonematt: I wanted to call out Christopher on this topic because he was bringing this up maybe a little bit based on implementation work and he may have insight.

ChristopherA: Let me paste an issue:

<ChristopherA> https://github.com/WebOfTrustInfo/btcr-hackathon/issues/25

ChristopherA: So of the issue is -- what is the kind of revocation that there is. You can have these revocations of ancillary trust items that are independent of the revocation of the VC itself and then you have this opposite case where you have some kind of enduring proof of things being true in the past whether they are still true today. My favorite quote in there from Peter Wooley is that censorship resistance is a key thing ... it's one thing to have

censorship resistance at issuance, you just get a new one if something happens, the real challenge is how do you avoid it on the revocation. Depending on the many types of revocation ... not trusting a key after such and such a date but before that is ok

scribe: everyone needs to have it

ChristopherA: This isn't the only place this issue came up but it's an important one.

<ChristopherA> Yes, that is accurate!

stonematt: We haven't really spent must time on the topic yet, I get the sense from your intro and experience and there may be a chain of things to validate to true in order for the claim to come back as verified. If that's a simple enough way to state it. Is that the right way to interpret that? From the perspective of the data model, what sort of language or terms do we need to be thinking about?
... The claim was true at some point or was revoked, etc. or what sort of language do we want for that?

nage: There's a number of things that help with this, splitting a part the construct of whether the claim is true or whether it was revoked. Having an inventory of the things we expect the inspector/verifier to verify and in the right order and the oracles for that information will be perserved when aspects of the info changes and calling out the order ...

<ChristopherA> https://github.com/WebOfTrustInfo/btcr-hackathon/issues/5

nage: And how each of those checks is performed is important for privacy, dont' want to do unnecessary correlation/can undo privacy protections when doing revocation. Need to get the data model right. I know Christopher and their groups have techniques to address that and so does Sovrin.
... Making sure all of those are on the table is important.

<SeanBohan_Evernym> I am

<burn> dlongley: in the data model spec we need to define where abstractions occur, different signature mechanisms. There will be interactions between those other methods and the data model. Need to bind them somehow. Those details need to be in the signature method. We need to outline this in the DM spec. If you are going to protect these claims with cryptographic method x, these are the steps and privacy consideratiotns

ChristopherA: I posted a little diagram that we had started, that is not a great diagram but it shows why we're having problems with this kind of stuff. There's the integrity of the claim. That's the word we're using the bottom level. Before you try and figure out the trust model, you have to basically look at the integrity of everything. Then there's this next stage where we have to get into inspector-verification issues...
... You have different things being checked and purposes and on up the chain for what's required. Different kinds of revocation are significant because they aren't about the data but the trust model. I appreciate Dave saying that this goes into the signature model or whatever. My gut feeling is that it's an issuer thing and it may be a relationship between them and the inspector. The issuer can say "I'm only issuing this if you're willing to do

these checks", e.g. you confirm the DID, you have an authoritative check...

ChristopherA: That may be required as part of the claim.

<burn> dlongley: agree that there are other aspects we want to put into data model. Some of those components might go into the methods used. There might be some not specific to the signature method that must go into the claim itself.

dlongley: There may data model elements we need to define or at least extension points, where we have a common vocabulary of enumerated types that define verification requirements for claims that issuers can tag on their claims -- and inspector/verifier software can implement.

TallTed: I'm getting a fairly strong sense that, as much as work has gone into this over the past works, there hasn't been a concerted effort to do process flow mapping.
... These are our processes, how can we make them simpler, better, code modularization. It is nitpicky and can be painful to do. One of the examples -- is people going into a restaurant, sitting down, ordering, getting food, etc. Lots of roles involved. Sometimes one person does more than one thing. Sometimes more than one person does more than one thing at a time. The terminology exercise has been exposing this problem, which is echoing in every

other topic that comes up. This is a complex thing, this is a complex thing -- verification of claims. There are so many things, what identifier and keys and chain of custody things, all these matter. I'm not sure that any primitives have actually been captured aside from the subject of a claim. To some extent the issuer of a claim.

TallTed: I'm not sure we need to capture every possible agent relationship, partly because you can have an agent of and agent, umpteen layers deep. Trying to express that in the basic level makes that incomprehensible to both new comers and those with a fair understanding of what's going on. I think that's the thing that we need to put substantial effort into that possibly to the exclusion of everything else

<ChristopherA> I have a process comment toward end of meeting about what we can or can't share from these meetings.

stonematt: How do we get the group engaged to make progress?

<ChristopherA> #RebootingWebOfTrust is good for this kind of thing

<burn> dlongley: Ted is right that we need to document more. Much of this information is tribal or in implementations but needs to be captured. We will need a process to do it. There actually has already been much discussion around this, just maybe not the documentation.

nage: My question is that we've been trying fairly hard to avoid protocol details and how those relate to the data model. What Ted's pointing out is that there are process pieces that are important to our data vocabularies. How do we want to extract some of that tribal knowledge?

+1 we have to remember protocol is out of scope so this is tricky.

varn: I'm a huge fan of process mapping. This often devolves into being atomistic or synthetic. There has been work done on this and flow maps in the documentation somewhere, someone should be able to point to them.

<burn> we can discuss protocol as needed to understand data model. We just can't write it down :) But the CG could ....

varn: We've done some to lay out of the flow of those steps. We do need to be atomistic on what the pieces are. I threw a batch of the possible names for the other roles into github. Continuing on the atomistic parts and working on teasing that out online in a scenario and that should help expose if we have the roles and tasks worked out and this can inform us and we'll get feedback and this is best done as a dynamic.

burn: Any other questions on process moving forward, specific topics of revocation, validation, etc. Goal today was just get the discussion started. People should create issues in github and discuss there.

ChristopherA: I do believe that this needs to be teased out. I think it's something that's very hard to do online and through issues. The best ways I've ever seen it done was drawing on a big whiteboard with 5-6 people constructively breaking things down into little pieces and such. That's something that RWoT is really good at. We could do it during TPAC if more people are involved there. I don't quite know how to do it online easily. It's just too big,

you need a big canvas to tease it all apart.

ChristopherA: I know October is a long time away and I'm willing to work on it before then, just not sure how.

burn: That was going to be my comment. Can definitely use time at TPAC for that. It's going to be a few months before we get there.
... I think it's worth it for people to take some time to think about this. The chairs of course are always discussing process and how to get to a resolution. Continue having discussion and chairs will continue to help guide discussion. We only have five minutes left today.
... Any comments on anything else?

ChristopherA: This has to do with the change over to being a WG and confidentiality things there. Are the minutes public?

burn: All minutes are public.
... When we send out the link to the minutes, it's publicly visible to everyone.
... So you can point to it or to the minutes as you wish.

TallTed: I was not trying to suggest that the work hasn't been being done, it was more of a question about putting it into a form that is consumable for others, including new participants like myself.

<ChristopherA> Ciao!

<liam> [it seems there may be rooms available in a different hotel - I'll follow up with email to member-vc-wg as soon as I can get the details]

Summary of Action Items

Summary of Resolutions

  1. For the FPWD we will use the following terms: for the first role Issuer, the second role Holder, and the third role Inspector-Verifier, with a note explaining that the third term is hyphenated because of a lack of consensus, to be resolved in future discussion.
  2. After updating the Data Model document to incorporate the terminology decision above and Christopher's request, the group approves publication of the Data Model specification as a FPWD.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/07/11 16:02:23 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/anyone else/anyone else believes/
Succeeded: s/hasn't been done/hasn't been being done/
Succeeded: s/Process comment//

WARNING: Replacing previous Present list. (Old list: Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg, stonematt)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg


WARNING: Replacing previous Present list. (Old list: Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg, Matt_Larson, Richard_Varn)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg


WARNING: Replacing previous Present list. (Old list: Adam_Migus, Charles_Engelke, Christopher_Allen, Christopher_Webber, Colleen_Kennedy, Daniel_Burnett, Dave_Longley, Gregg_Kellogg, John_Tibbetts, Matt_Stone, Nathan_George, Sean_Bohan, Ted_Thibodeau)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Daniel_Burnett, Christopher_Allen, John_Tibbetts, Colleen_Kennedy, Matt_Stone, Adam_Migus, Dave_Longley, Ted_Thibodeau, Nathan_George, Christopher_Webber, Gregg_Kellogg

Present: Daniel_Burnett Christopher_Allen John_Tibbetts Colleen_Kennedy Matt_Stone Adam_Migus Dave_Longley Ted_Thibodeau Nathan_George Christopher_Webber Gregg_Kellogg Matt_Larson Richard_Varn Sean_Bohan Charles_Engelke
Regrets: Liam
Found Scribe: dlongley
Inferring ScribeNick: dlongley
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Jul/0002.html
Got date from IRC log name: 11 Jul 2017
Guessing minutes URL: http://www.w3.org/2017/07/11-vcwg-minutes.html
People with action items: 

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


[End of scribe.perl diagnostic output]