Verifiable Claims Working Group -- 25 Jul 2017

<scribe> scribe: manu

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

Agenda Review

stonematt: Short update on FPWD, then bulk of the day is focused on shifting into next topic - validation and revocation, which we started last week.
... I'd like us to focus on how to structure the next phase, not focus on what it is, but how we go about making progress on those topics. We're open for suggestions for next week's agenda.

<dlongley> manu: I don't know if we have an editor for the use cases spec any more, current editors busy. I'm not sure what the group will be discussing after revocation and validation errors, so I'd like to see if we can discuss where we're going a bit further down the road today.

manu: I'd like for us to prioritize issues for Q3 and then Q4.
... With a focus on getting to a test suite.

stonematt: We have TPAC coming up in the next couple of months, we need to talk about Agenda for TPAC.

<dlongley> manu: We may want to also plan a few other events at TPAC. Plenary day on Wednesday, unconference. Would be good to prime the membership and to come in and find out where we're going with this work. Coordinate with the CCG to figure out messaging on Plenary day. It's the day to set up what's coming next. We want to advertise that early and often to the membership.

<DavidC> How can I get the pw for the webex page?

<dlongley> manu: If we end up rechartering this group for the next steps it would be good for the membership to be aware of it and provide input.

<dlongley> manu: So breakout sessions on VCs self-sovereign stuff and things of that nature would be good.

<stonematt> webex callin data is here: https://lists.w3.org/Archives/Member/member-vc-wg/2017Apr/0000.html

<DavidC> >manu, thanks

Introductions and Re-Introductions

stonematt: Any new participants today?

<DavidC> No the PW did not work on webex

<ChristopherA> I'm hoping that people saw Anil John's twitter moment https://twitter.com/i/moments/888780606334787584

<DavidC> OK, waiting for Liam's email

dlongley: Hi, Dave Longley - we work on Web Payments, identity, and blockchain. We helped start the Web Payments IG/WG, Credentials CG, and Verifiable Claims WG.

Status of FPWD

The FPWD-ready document is here, which passes pubrules and link checker: https://w3c.github.io/vc-data-model/WD/2017-08-03/

<dlongley> manu: I applied the terminology fixes including the update to Inspector/Verifier. I added an issue based on what I could divine from the minutes. Number of roles, expected terminology, that kind of stuff. I made updates to spec to pass pubrules and link checker. A few validator errors still happen but I think those are ok and maybe a bug in the validator.

<dlongley> manu: I can talk with the w3c pubrules team about that. I did find 3 bad links in the spec, so before you send it out for publication, Liam, I'd like to address those. Other than that I think we're good to go. I believe I've addressed all issues for publication. The publication date is for Aug 3. two weeks from today to make sure all the proper levers can be pulled at w3c. Plenty of time to deal with administrivia.

<dlongley> manu: Good to go for FPWD.

<liam> [let me know when it's ready]

manu: I'll let Liam know when it's ready.

Issues around Validation and Revocation

stonematt: These are topics that are important for implementers to document. We had a discussion around what is in scope for data model, and what's out of scope (protocol).
... I want to understand how we're going to close the loop on these items to get implementers going on data model and spec today.

<Zakim> manu, you wanted to ask that we plan "other" stuff at TPAC as well.

stonematt: I'll open the floor to how we've done this in the past. Manu and Christopher have to submit some text.

ChristopherA: I wanted to point people to Anil's conversations that he started - https://twitter.com/i/moments/888780606334787584
... There are misperceptions on Verifiable Claims - the Presenter is not necessarily the Subject, might be most controversial point, but is whole point of this architecture. It's worthwhile to look through that discussion and think about what it is that we can do to make it easier for these discussions to happen outside of this community.

<dlongley> manu: On the topic of how we're going to process these issues, the onus is on myself and Christopher to propose some text around verification. "How do you know whether or not this VC meets your needs?" That's the general discussion. We will have a section in the spec indicating the sorts of the checks you can run. Christopher and I need to author something, so we're blocked on us, there's not much more we can discuss on the call.

<dlongley> manu: We can discuss that topic for months or we can propose some text and then have people pick that apart on the calls. So a PR from Christopher and me is needed.

<dlongley> manu: Revocation is a subprocess of the verification/validation process. We haven't picked what word we're using verification/validation/etc yet, so using them interchangeably. We should have a good complete list of steps. Revocation is one of those steps. Whenever we talk about those things, Revocation should always be considered as a subpart of this validation process.

<dlongley> manu: In the spec, the section should probably be verification/validation as the top most level and a section on Revocation in there as a subtopic. Currently we have it as being completely separate in the spec. I'm a bit conflicted from an editor perspective -- do we want to describe revocation in the data model and then refer to that later or do we want to have a revocation section and then talk about how to do it in the data model.

<dlongley> manu: So I'd like to hear from others what they think.

<dlongley> manu: Or should data model be very light? And then shove those bits into that section.

ChristopherA: Small point, there is a difference between "what you check for revocation" vs. "the process that you go through to revoke".
... In the data model, we can focus on "things that you check to see for revocation", but actions to revoke something should be separate.

stonematt: There is a difference between what we report and how we report it... We have to understand the "how" to what we write down in the data model. When I think of the things that have to be able to be done - we have to issue, we have to store, validate/verify, we have to revoke... those beg to be primary sections in the data model. That may help you think about it. Validation is just a check on the claim. So we probably need a bit of both, that language

will lend itself to one path or the other.

<ChristopherA> catch-22

DavidC: I think that the actual revocation process may say what's in the data model. I'm not sure how we can have a data model when you don't know what the revocation process is.

<ChristopherA> Credentials Group will try to do first pass.

stonematt: We have challenges like that in this group - we're restricted to data model here, our boundary is gray, it will continue to be a challenge to navigate that.

DavidC: Is it possible to put into verifiable credential that says "revocation method" and that's a URI to be determined, so when you get around to defining revocation process, you can do that... alternate revocation methods.

stonematt: Maybe we can side step based on stuff in 'revocation' parameter.

dlongley: I wanted to briefly respond to DavidC - we can define specific guidance... this is the information you need... we have this in the spec now.
... What should we do in terms of editorially - we should separate out data model, not introduce ideas early or piecemeal - each section belongs in spec because we have data model specs. We are bringing in process/data model - if we can have pieces of data model in each area, we can be specific about ... each data model section should be qualified - we don't want one huge data model section. People will look at something and say something is out of scope.

We should talk about each piece of entire framework one at a time, and in each section talk about how it affects data model.

<stonematt> +1 process is context for datamodel elements.

<Zakim> manu, you wanted to say something controversial - "process to revoke is out of scope" and to note that his comment is no longer controversial. :P

https://w3c.github.io/vc-data-model/WD/2017-08-03/#revocation-model

<dlongley> manu: Process of revocation is out of scope at this point. I agree with David Chadwick that it's hard to specify a data model when you don't know what the process is. But what Dave Longley was saying and what David Chadwick ended with is that we can say "there's a slot in the data model where the revocation model will live" without specifying in detail what the revocation model is. We're going to have many different types of revocation models. You can

<dlongley> publish a file to a website, you can use a blockchain, and others. Each has a different process and data model. There won't just be one way. So the mechanism that we use should be fairly flexible.

<dlongley> manu: That said, we really should specify one to demonstrate it works. The CCG could do it, for example, doesn't have to be in this group. We do have to make sure that it works if we're putting it into the spec. Doing two different revocation methods with interop would show it works.

<dlongley> manu: It's not rocket science, I'm not that concerned about it. The data model for revocation can be fairly generic and then specifying one simple implementation showing how you'd do a revocation spec and then doing one experimental implementation outside of the group. If we do those things, we will have all bases covered and we'll have a solid revocation section in the spec. I suggest we do this. Based on the other feedback that I heard just now, what

<dlongley> Longley said resonates the most, which is don't just talk about the data model in the abstract. And this goes to what Matt Stone said, talk about we need to able to do with verification claims in the ecosystem, like issuing, verification. And when talking about those actions specify how those actions are supported by the data model.

<dlongley> manu: That's different from what we've been doing so far but we tried that in JSON-LD and people felt that it worked out well there. Thanks and I think I know how to talk about this stuff now in the spec. Now it's a simple matter of putting spec text forward in the group

<dlongley> It will also make it easier to add future specs in the same format that actually *do* get into protocol and process.

<dlongley> and read them together.

<ChristopherA> (my comment is on structure)

stonematt: We were time boxing to 15 minutes - we're at 20 minutes... let's hear from Ted and Christopher.

TallTed: I'm hearing more blurring of lines, this is about confirming that a given claim was issued by a given source.
... Revocation is being talked about in a few different ways here - I don't know if these are applicable to verifying whether a claim was issued by a given source. Was it cancelled properly? These are different questions, they should be part of the question, but they are extensions. They are well beyond "did this statement come from that source".
... That sort of amorphously expanding topic set seems like a recipe for endless discussion, frankly. The way the most of the framing for revocation constantly blurs the lines.

<stonematt> +1 bring us back to the fundamental question "was this claim issued by this source"

ChristopherA: My proposal is that there are some things that we can say - "is the DID revoked?" - you have to check the DID, the spec doesn't say anything about how it's checked, how it's checked
... Are the keys revoked or rotated - we should suggest something about that. You don't quite know if its revoked, rotated. Then there is "is this specific claim revoked"? Ancillary revocation style stuff, like Subject refutes it.
... Knowing whether or not DID is revoked - BTCR has a technique, second technique to deal w/ keys being revoked/rotated. Two different methods, data model way, update the issuer's copy of claim - newer date... revoked, list in different object - list and reissuance of claim. This particular one is revoked.
... The other two are outside of data model spec, you should check to see.

stonematt: We need something more tangible to discuss/debate - we need spec text.
... If we don't have anything more pressing wrt. process, we need to move on.
... Any objections?

No objections.

<dlongley> Will just say in IRC: I think what we want to do will address TallTed's concerns ... we want to have an overall validation/verification section ("Is the claim valid?") where we put these more concrete examples/ideas into subsections.

Outstanding Issues in Github Repository

<stonematt> https://github.com/w3c/vc-data-model/issues

stonematt: Which of these issues are necessary to resolve to start implementations.

<dlongley> manu: What we've found in other groups is that it really helps to create short milestones and focus on what we need to do implementations on those. Going to what Ted just mentioned, let's talk about the core mission. We need to able to issue a verifiable claim that has something in it that lets you know who the issuer of the claim was.

<dlongley> manu: That's minimum viable test suite/implementation -- it needs that before doing anything else. I'd like to set a milestone in the issue tracker for a minimum viable implementation. Can you issue a verifiable claim and have someone check the signature on that and have something good happen. We've got interop between two implementations and both issuing and verifying the signature (just the signature) of the claim. I have a feeling that we may already

<dlongley> be there.

<Zakim> manu, you wanted to request we move to Pre-TPAC, Q4 issues.

<dlongley> manu: I'm guessing that there should be no issues put into that milestone. We should be able to do that today. However, there may be people in the group who feel we can't do that today. I want to set a 1 month milestone to have people move issues into that milestone so that they think have to be addressed for that simple case. If we find out we're in good shape there, then the group should figure out what the next atomic thing is. Others may say

<dlongley> revocation list, others may say proof that went into the creation of the claim, or whatever. I'd like to move the group towards a short term milestone based approach.

<dlongley> manu: Focusing on implementations. Pausing here to see what the group things on that approach or if there's a better way.

DavidC: I think that's a good approach, wrt. with Revocation - it isn't essential, you can issue non-revokable credentials. There is one thing missing from that proposal - Is this verifiable claim appropriate for use by person presenting it? Just that it's been issued, and valid, doesn't mean Relying Party should rely on it.

<stonematt> judging fitness isn't our mission

DavidC: I could take someone's passport and become American... you have to have proof of possession.

stonematt: I don't think our mission is judging fitness of use - we need to figure out if a receiver can decide

<dlongley> i think our mission to show how to model these elements -- or to at least provide a framework and extension points for modeling these elements.

ChristopherA: There are some things that are very implementer oriented short term - I'd like to have some closure on expiration and how that works, how it differs, etc. I think that's simple, straightforward, I need it as an implementer. There are some big scale things that worry me. There seem to be people that want to use Verifiable Claims for evidence, reputation, etc. It's in the 3 kinds of claims paper, I want to be convinced that our model supports that now.

<dlongley> we want everyone using VCs to expect to find the elements in the same place, modeled using the same framework -- but where the specifics are extensions.

<Zakim> manu, you wanted to support DavidC's proposal - we need to make sure data model supports proof of posession.

ChristopherA: I think that has been one of the propositions, but it may be a longer-term discussion. Dividing into categories by people implementing is important to me. There is a lot of bikeshedding that can happen from non-implementers, and that worries me.

<dlongley> manu: Yeah, I just wanted to underscore David Chadwick's point. I think he's right. Here's where. The data model has to suppose proof of possession. Matt, you're right -- that defining proof of possession is outside of the group, but the data model must show how it supports it.

<dlongley> manu: The good news there is that we have a story there as an added signature on the entity profile.

<stonematt> q/

<ChristopherA> (I have to go to Credentials WG as I'm hosting — Ciao!)

<dlongley> manu: Making sure the data model supports it is in scope, potentially defining them specifically could be out of scope. We just need to demonstrate that it can be done.

<dlongley> manu: We shouldn't be quick to say what David is out of scope, a part of it definitely in scope and absolutely required.

stonematt: We're out of time, unless there are any questions/comments, we'll close up.

<TallTed> TallTed: not saying it's out of scope, but it's definitely downstream

- DRAFT -

Verifiable Claims Working Group

25 Jul 2017

Attendees

Contents

Agenda Review

Introductions and Re-Introductions

Status of FPWD

Issues around Validation and Revocation

Outstanding Issues in Github Repository

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output