See also: IRC log
<cwebber2> trackbot, start meeting
<trackbot> Sorry, but no Tracker is associated with this channel.
<TallTed> trackbot, start meeting
<trackbot> Sorry, but no Tracker is associated with this channel.
<TallTed> trackbot, this is VCWG
<trackbot> Sorry, TallTed, I don't understand 'trackbot, this is VCWG'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
Kim_Duffy: our W3C membership
just kicked in, so this is my first meeting. I work as a
principle architect at Learning Machine, working on Block Certs
with MIT Media Lab.
... I’m interested in the goals of this group. I’m also
co-chair of the Credentials CG.
<stonematt> zakim pick a victim
ChristopherA: Along with Kim, I’m
chair of the Credentials CG in the W3C, I represent
BlockStream.
... Individually, I’ve been hosting Rebooting Web of Trust
community, who’s goal is to go back to the PGP roots of 26
years ago with something better. We’ve had 4 gatherings with
specs for the last couple of years. We just had a virtual
hackathon, with good results.
stonematt: Manu sent regrets, but his expectation is to have a spec ready for pub by next call.
<ChristopherA> The issue where this was discovered: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/issues/12
stonematt: Christopher sent a note from the hackathon on experiences.
<stonematt> ChristopherA email re morning discussion: https://lists.w3.org/Archives/Public/public-vc-wg/2017Jul/0005.html
ChristopherA: This issue is from
the hackathon. I’ve been developing a user model for how Web of
Trust (WOT) would work. As an example, a daughter of imigrants
wishes to contribute to efforts back in her homeland, but fears
for sticking out, so is using pseudonomous technologies.
... Part of the purpose of the hackathon was to work around
this using the DID anonymous identifiers scheme.
<ChristopherA> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/issues/12#issuecomment-315569411
ChristopherA: Within that issue
is the just mentioned sub-issue that basically has discovery.
Basically, what was intereseting was that there was an in-out
process to get a result that we could say was “verified”.
... NIST has a document that talks about verification, which
says “you should only collect the information which is
necessary to validate the identify for validation and
verification” (but they don’t explain the difference).
... I’ve chosen the words becaused VC has chosen them.
... VC means everything is complete with no inspections. We
have an integrity check to look at aspects of the object
itself, which might note it uses a particular signature
mechanism. Then, you have to go inside the object to know what
you need to look into further, for that I use “inspect into” to
be clear that you need to know something about the object to
continue, which is defined by the data model spec.
<manu> I assume we're talking about this comment? https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/issues/12#issuecomment-315569411
ChristopherA: From there, we have
a variety of objects that need to be validated further, that’s
the DID spec, look at the issues DID, which is incomplete, and
need to go elsewhere. We need to inspect other aspects, which
leads to a big loop of checks and validations. After that’s
complete, I can then call to have it verified.
... The discovery became more complex, as there’s a step above
the VC, it still doesn’t necessarily mean you can trust it. In
a centralized model you have the “root” of the certfificate;
why trust one vs the other?
... I’m calling that stage “confirmation”, which comes form the
BitCoin perspective. They have a concept thata just because
something has been verified, you still want to wait for 6 more
looks before it can be trusted.
... Finally, I delved into revocation, at the highest level,
it’s what to do when things go wrong, but it relates to
everything else. It can happen at any level. Then you have
something which is outside of the loop, where something else
have gone wrong. Clearly, revocation is overloaded, and there’s
aspects that can apply at all levels.
... I encourage you to take a look at the full user story,
which is in the topics directory of Rebooting WOT.
<Zakim> manu, you wanted to discuss difference between "verified" and "verifiable"... and need for "verification process".
manu: We have a raised issue about what the process is you go through to change a verifiable claim from “verifiable’ to “verified”. This is a good first step, the next step would be to put something like this into the data model spec.
<ChristopherA> (from the subissue) the logic of my ordering of these different spectrum words started with the name of the working group, Verifiable Claims.
<ChristopherA> INTEGRITY CHECK includes malformation and cryptographic signature or proof checks - this is defined by the signature system spec
<ChristopherA> INSPECT INTO means looking inside for something and then going outside to get it — this is defined by the data model spec
<ChristopherA> VALIDATION means that the conform to rules of the DID spec and the specific DID method.
<ChristopherA> VERIFICATION means that that everything is self-consistently INTEGRAL, the INSPECTIONS reveal no problems with VALIDITY, and thus the whole can be VERIFIED.
<stonematt> manu is it this? https://github.com/w3c/vc-data-model/issues/9
manu: Depending on the claim, you may skip steps or have other steps to go through. +1 for tetting this going.
<ChristopherA> CONFIRMATION relies of the VERIFIABLE CLAIMS to then make possibly more human judgements on different trust models to be used by the Web-Of-Trust. It also somewhat analogous to Bitcoin's terminology, where transactions require multiple CONFIRMATIONS.
<ChristopherA> REVOCATION deals with the edge cases where things go wrong. There may need to be processes associated with "where things go wrong" at each the stages above, as revocation currently may be an overloaded term.
manu: The group is called the
“Verifiable Claims WG”, not the “Verified Claims WG”. We have
to be careful to not make guarantees about soething being
verified.
... We’re talking about the verification process, as a results
I think the wording is good. Nate Otto has some other words to
add to it.
<varn> I would add that verifiable also means that an inspector, if authorized to do so by the subject, can look inside the claimvelope and review the evidence relied upon by the issuer and decide if they consider it sufficient to accept the claim.
manu: The other point is that the
more speciallized terminology we create, the harder it is going
to be for other people to understand it. I’d rather we focus on
the process, and think careful before adding more terminology,
but rather focus on what actualy happens.
... The concrete request is to get this into the spec as a set
of steps you go through.
ChristopherA: I agree with what
manu said, the words can be a rat-hole, but I didn’t hear about
the fact that it became clear we need to know what spec does
what. The space of the different pieces of a VC, and how they
come together as a whole into a VC that can be considered to be
“verified” at that point. We don’t have a spec on what it means
to confirm it, and also have this revocation thing which
touches all of them.
... I’m trying to weave something aroud all the different
specs.
<TallTed> side note -- Please expand all acronyms/abbreviations on first-use in any document. e.g., DID has multiple expansions (apparently 44! http://www.acronymfinder.com/DID.html). Distributed Identity was not the first meaning that I applied in reading, and makes meaning #45.
varn: I like Christopher’s narative, and that it is non-normative. This is an example of the different components that need to be part of the process. I don’t know if we need to name them.
<manu> I found it! Here's Nate's work on the list of validity checks to verify a verifiable claim: https://github.com/w3c/vc-data-model/issues/9#issuecomment-281394529
<ChristopherA> +1 on evidence — it is needed for CONFIRMATION
varn: The whole idea of verification is really a 2-step process. One part Christpher descdribed. The other part is to look at the evidence you have and decide if you believe it.
<ChristopherA> BTW, here is the full Alice WoT user story: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/RWOT-User-Story.md
Nage: There’s the idea that your revoking the VC, or that you’re revoking the keys used to make the credential. We need to call this out.
<ChristopherA> iso documents are not public, anyone send me a copy with those definitions.
amigus: The definitions that NIST works form are based on ISO, and the working definitions are verifies that it works correctly, and validates that it fulfills an intended function. They’re still debated, but the basics
<Zakim> manu, you wanted to point out Nate's work and to separate out "Revocation" from this discussion, which can be implemented in a variety of ways.
manu: I found the work Nage did on this.
<manu> Nate's work on the verification process: https://github.com/w3c/vc-data-model/issues/9#issuecomment-281394529
manu: This is input that
Christopher mentioned, as long as the others.
... The topic has revocation, but we’re reallly talking about
the process and language about it. There are many different
ways of doing revocation. This now specifies a real simply
mechanism, but not that it is the only way to do it.
... That’s a tar-pit that could consume us. The spec just needs
to show one way to do it, in addition to making it extensible
to allow others.
... I’d like to split that issue out.
<TallTed> TallTed: key detail of revocation is revocation *of what*. claim, certificate, authority, etc.
<TallTed> TallTed: also, difference between revocation vs retraction vs refutation
ChrisopherA: My challenge is that
as soone as you usse the word “revocation”, it becomes a
rat-hole. You mentioned 2 things that were revoked, but I can
think of more. There’s a word “refutation”, as well. Sometimes
that is what is needed, to say that something is false at
confirmation level all the way down to the key failure, which
is diffferent than the “revocation” act, which is after
everything has been done.
... If we’re clear that things can be true/false at different
levels, it’s different than the explicit cancelation after the
fact, even if we don’t use those specific words.
<ChristopherA> Revocation: the official cancellation of a decree, decision, or promise. Refutation: the action of proving a statement or theory to be wrong or false.
stonematt: This discussion seems
pretty essential as we understand how the echo-system works and
get some experience. As I listen to the discussion, we talk
about keys being revoked or rotated, and DIDs, but those should
be the provenance of the DID spec.
... We just need to know how to implement their veification as
a loop in our data model.
<Zakim> manu, you wanted to be specific - revocation of the verifiable claim, specifically the identifier associated with the verifiable claim. and to note we're having another terminology
manu: This discussion
demonstrates that there isn’t clarity about what we’re talking
about. When I said revocation before and that we needed to put
something in the spec, I was being very specific about the end
result. The process you go through is important, and we may
want to talk about it in the spec, but what I’m looking for as
an editor is: which property to you use to say it’s revoked?
This is specifically not refutation, which IMO is out of
scope.
... We’re talkinga bout an issue retracting something they
said, and the revocation of the VC (it’s id). I’ve issued an
issue with this id, and I’m now saying that it is invalid. The
way you go to discover that is to go through a field in the VC
and implementing whatever revocation mechnism is there.
... We need to suggest at least one revocation mechanism that
we believe will be fairly easy to implement. It may not have
the anonymity we want, but we need to specify something.
... The converstaion Chistopher is talking about shoul happen,
but perhaps in the CG. The result of that should be something
tangible in the VC data model spec.
stonematt: for next steps, we
need to reconcile Christpher’s note with Nate’s and come up
with a straw-man for a document in or next to the data model
doc to discuss revocation and result in a VC that rings
true.
... We can put some structure around the discussion and get
some language that could go into the data model.
<manu> +1 to that being the right next step, I think ChristopherA should lead that discussion.
ChristopherA: I think there is a
concept of something that is explicitly higher-level than the
VC. we might call it “confirmation”, and say that we don’t do
that.
... That’s a good piece to untangle out.
<ChristopherA> (BTW, this issue is also entangled with privacy requirements)
stonematt: I understand where manu is coming from about being careful that we don’t assert something is “Verified”, but we need a way to talk about a positive outcome of such a process.
<Zakim> manu, you wanted to suggest that ChristopherA suggest some language
<varn> i think the phrase that will be true at the end of the verification process is that the claim was accepted or rejected by the inspector. The fact that a claim is accepted or rejected be a data element or could become a new verifiable claim.
manu: I’d lke Christopher to take
the lead and look at other terminology and Nate’s stuff and get
a proposal for language to put in the spec.
... We should talk about the verification process in the
spec.
<manu> Link to the Verification section in the Data Model spec: https://w3c.github.io/vc-data-model/#verification
manu: We talk about structural validity, entity validdity etc. Once we get that in there it can be refined. THis might take a couple of months to get through.
<varn> +1 for putting them in that space per manu
TallTed: One of the challenges we’re going to have is what does verifiable claim mean? My understanding is that the verification is to say that source emitted this claim, and nothing more. Not to say that it is true.
<manu> +1 to TallTed - yes, that's exactly the purpose of a verifiable claim... not to say "This is the truth", but to say "I know who said this, they still assert this, and it's up to me to do something with that information".
<stonematt> +1 to TallTed scope of VC
<varn> if it is about a subject, the association between the claim and the subject should be part of it as well
TallTed: We care that it is represented accurateliy, and came from the source the presenter said it came from, and the technology needs to support this. Basically, we’re verifying the provenance of the claim, not the accuracy.
<JoeAndrieu> +1 provenance, also currency (via non-revocation)
<varn> and whether the subject has given permission for the claim to be inspected must be verifiable
ChristopherA: I’m reluctant to take it alone, as I’ve found it needs more back and forth, and I think we have a lot of stuff that feels entangled. That comes back to things like the language we’re using for the roles. I’m still uncomfortable with some of the terms, and this has impact on the language. If we take Ted’s possition, those roles are conflated with other things.
<JoeAndrieu> @varn I think "verifying" anything about the subject is extremely problematic
ChristopherA: I don’t know how to untangle things, I’d love to see the ISO specs. I’m willing to join a task force that might meet about this a couple of times, but I can’t take it on my myself.
<manu> maybe this is a topic for RWoT?
ChristopherA: This is an issue for RWoT already.
manu: This is an iterative process; we need to put something out there that can be revised. I can talk a stab at it after FPWD and attempt to collect other things; I think I have a concpet on how to start doing that. If people scream, at least we know that and can go elsewhere.
<ChristopherA> Please do!
manu: Ted hit the nail on the head, which says we’re not that far off. If Christopher is okay with my trying to merge this we can make a second pass and see if it aligns with everyone’s thinking.
<kimhd> I'm happy to review, and I can probably sync up with Nate Otto on it as well
<manu> +1, great, thanks kimhd!
stonematt: next week to 10 days we’re about the FPWD. What items should we cover in next weeks call?
<varn> @JoeAndrieu i agree but we have put the idea that a person identifier can be part of a VC so we have the issue to address regarding whether the person subject of the claim has and identifier that is sufficient to allow one to associate the claim with them. Whether it is sufficient is up to the inspector.
stonematt: It would be nice to have something processed before we spend call time.
ChristopherA: A number of interesting things came up when we were trying to do VC for WOT. Maybe not next week, but at some point soon, I’d like to have various examples and pare them down in the a relativeliy mature set of examples that work.
<manu> We were supposed to do that here: https://github.com/opencreds/vc-examples
<manu> (no one has submitted anything yet) :)
ChristopherA: WoT example, education, health. Works with JSON-LD, signature systems, DIDs, etc. Has proper sub-names, key-names, etc.
<Zakim> manu, you wanted to ask about status of FPWD - we're good to go w/ editor edits? Date?
manu: My understanding is that the group approved pub of FPWD. If we pull work that’s out there, are we still go with FPWD. Can we set a date? e.g. next thursday?
stonematt: We did approve publication. We approvied Inspector/Verifier. Otherewise, we agreed to move forward with FPWD and Thursday would be a good target.
manu: I want to be sure noone’s planning on a formal objection?
stonematt: no one mentioned anything.
manu: So we won’t be talking about FPWD next Tuesday.
<kimhd> thanks everyone
stonematt: We’ll put a call out for agenda items.