See also: IRC log
<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.
<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.
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?
<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.
<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!
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"
<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]
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]