W3C

- DRAFT -

Verifiable Claims Working Group

09 Jul 2019

Agenda

Attendees

Present
Dan_Burnett, Amy_Guy, Andrei_Sambra, Adrian_Gropper, Dave_Longley, Ted_Thibodeau, Matt_Stone, David_Chadwick, Dmitri_Zagidulin, Manu_Sporny, Jonathan_Holt, Ken_Ebert, Justin_Richer, Sercan_Kum, Kaz_Ashimura, Kaliya_Young, Tzviya_Siegman
Regrets
Brent_Zundel
Chair
Dan_Burnett
Scribe
manu, burn, rhiaro

Contents


scribenick: manu

Describe plan for the call

burn: Plan for the call is...
... This is the same Agenda that we have typically, but an additional set of things today... we're asking if the document is ready for PR?
... We need to know if we're done, what else might block publication?
... Beyond the document itself, what else is left?
... Not just the spec itself, but things that could affect the spec? Any other topics for today?

scribenick: burn

PR announcements

<manu> https://github.com/w3c/vc-data-model/pulls

https://github.com/w3c/vc-data-model/pulls

manu: we only have 2 left

<manu> https://github.com/w3c/vc-data-model/pull/668

manu: was not on call where PR was approved, concerned that it included substantive changes. W3C process team says it is indeed a substantive change, even though all impls. did the right thing. changing the spec will force a CR.

<rhiaro> Extending the WG for *just this one thing* seems not unreasonable

manu: process folks suggested some options. we are talking with W3C management shortly (chairs + Manu). options are extending group charter, making the change and going through focused minimal CR for that feature (28 days). Approval usually takes about 3 weeks though. Could remove JWT section of spec and move it to another Rec track spec, but not ideal. We are between rock and a hard place here. It is up to W3C management on advising us how to proceed.

<rhiaro> I forgot there was already one admin extension

manu: extending seems reasonable, but we have already gotten our 6 months extension. Beyond that will probably require asking membership. Which can open us up to expected objections.

<manu> https://github.com/w3c/vc-data-model/pull/674

TallTed: W3M has got to get their act together. Ours is not an isolated instance, and it will get worse.

justin: just say the spec isn't ready. this is not the only issue that has come up over the past few months. maybe the group should say the spec isn't read.

<justin> +1 to long term fixes if we go there

DavidC: thx justin. wanted to say something similar. there were other issues where we might have wanted to change the spec. if we do another CR we should go back and fix those other issues.

<burn> -1 to fix fest that will not complete

<justin> maybe find a new SDO?

manu: chairs and i are concerned about re-opening a whole bunch of issues. then how much more charter do we need. That would mean going back to AC for approval. They might anyway. W3M could just end the group. No spec. We will discuss with them.

<justin> ok

manu: going to a new SDO could be tough at this point. Would open huge can of worms.
... WHATWG/HTML 5 battle was already an issue.
... this happens commonly in WGs. Every WG, right at the end, says the same thing "we need to go back and do X, etc" because the ecosystem is always changing.

<dlongley> +1 to ship -- and revise later via Evergreen

manu: so most groups just publish something to get a stake in the ground, then switch to CG, maintenance, etc.

<stonematt> +1 to ship and evolve. we will never stop learning and wanting to adapt/adjust.

manu: This is how groups fix these things without the arduous task of a charter extension. we will bring up with W3M.

<ken> What's evergreen

dmitriz: spec is not ready. we will go on to update in one way or another. have no doubt that we will fix these things in the future.

<manu> https://github.com/w3c/vc-data-model/pull/674

<burn> +100 to ship and evolve

<dlongley> https://www.w3.org/wiki/Evergreen_Standards

manu: DavidC, conversation has slowed down. We are at a standstill. Background: this PR tries to explain the type of types you can have in a VC, associated with cred subject, etc.
... think DavidC wants the language stronger with MUSTs, others assert that was not what we intended
... this PR looks at important nuances.
... Brent suggested maybe text belongs in impl. guide, Ted agrees, Manu agrees (at least from editorial perspective)
... group may never agree on what was always in the spec or always intended.
... a new CR where we try to get MUSTs/SHOULDs in would definitely push our group beyond its charter. At least in impl. guide we can give general direction.
... need input from others.
... without other input it really shouldn't go it.

DavidC: anyone else want to contribute here?

(crickets)

DavidC: I only want one MUST. I am adamant about it. Upset about implicit statement.
... to suggest other text is not to be in at all i feel strongly against.
... there are other issues that need to be fixed. Would like to understand a 1.1 process.

manu: W3C Advisory Board is aware of this kind of problem. Trying to make it so that after a spec has been published it's easier to continue fixing things.

<stonematt> but it requires that there is a spec to hand over... right?

manu: as long as there's consensus. Still only a proposal, probably not ready until next year, but we can hand spec to CG immediately when published and have CG publish a 1.1 doc. CG will be in charge of test suite. As long as we address compatibility, etc. we are fine. Work doesn't stop once 1.0 is done. Evergreen is a more formal way to do this.
... suggest reading through Wiki

<dlongley> This is the wiki Manu is referring to: https://www.w3.org/wiki/Evergreen_Standards

manu: it is better aligned with real world needs. But will still be >6 months before ready.

TallTed: as the author of the word "implicit", i have many times read the minutes involved and went with the mandatory base type because will lower the basis for entry.
... complex activity will be a future thing. VCs issued for one purpose will eventually be put to other purposes. Other subjects will be needed to be added on the fly. Current revision text says you have to put a URI pointing to your type, whatever it is.
... doesn't sayit must be resolvable by other verifiers. Other verifiers might not be able to get to and see these other properties.

<manu> +1 to what TallTed is saying right now.

TallTed: by adding this text it suggests a reliability which is not delivered. Better to leave it out and provide guidance that indicates pitfalls.

<manu> Excellent point, Matt... no idea why I hadn't considered that before... :)

stonematt: regardless of process track, CG or evergreen, both require a spec to hand over. So we must publish something now to have a spec to start from, or we can go nowhere. A 1.0 gives us a vessel for continued discussion.

<dlongley> +1 to matt

<manu> also, +1 to what Matt is saying.

stonematt: CG would be less formal than evergreen, but in meantime if we get to Sept. and end group with no spec, there is nothing to hand over.
... we would be done. over. can't move to other SDO for licensing reasons. Would only have an orphan doc in the marketplace in an odd state.

manu: if we don't get to Rec that is correct.

DavidC: nobody wants to delay spec. everyone here wants it to go out. a 1.1 will be essential. We all know there are weaknesses.

<stonematt> +1 to continue working on the spec post PR

DavidC: text I wrote says you are allowed implicit types for new attributes (?? got this wrong)

TallTed: implicit types for attributes?

<manu> DavidC: I'm talking about the top level properties in the VC.

<manu> DavidC: Is that what you were talking about TallTed?

DavidC: 3 ways for type to be extended: top-level properties, type of the subject (IoT device example), in the actual properties of the subject itself (adding marks to degree certificate). want Ted to be explicit .

TallTed: does anyone else think i was being vague?

manu: let's try something else here
... Ted is correct here, but David is making good points about what implementers should be aware of.

<Zakim> manu, you wanted to suggest a path forward.

manu: you want to make it more normative, but if we make it mandatory there is disagreement in the group on whether it should be or not. That means it is substantive.
... that would force a new CR. So how can we get to something acceptable, if imperfect, to everyone?
... list is much longer than David mentioned, but implementers do need to pay attention to this.
... this is a problem for David in his verifier, but not for others.
... we are not getting anywhere with current conversation. Understanding that we absolutely are going to work on a 1.1 in CG/evergreen, David would you be okay with taking the text, wording it more strongly, and putting in the impl. guide?
... if we do that we still have 3 months to work out that wording.

DavidC: no, would not be okay. insertion of 'implicit' statement is a problem. this text must go into base spec to limit the damage of this statement.

<Zakim> dlongley, you wanted to say i don't think this makes a lot of sense with selective disclosure

<rhiaro> scribenick: rhiaro

dlongley: it's a should that you include a type, not a must, and there are use cases for this

<dlongley> dlongley: There are a number of use cases that involve anonymizing data or selectively disclosing data where having a specific VC type just doesn't make any sense or isn't possible, I don't want to rule those out.

DavidC: I agree with what dlongley said, it's the associated bit of working that led to the confusion. I was very clear at the time that that wording was meant at a higher level. It meant you can put things lower down but the type would be associated at a higher level and not in the actual object itself. It didn't mean implicit. We had different interpretation. It was very clear that summary wording was needed, and there was some rewording proposed
... that clarified it meant at a higher level. But then the implicit crept in and that's where the problem started
... what i've tried to do in my clarification is say in these instances implicit is okay and in this one instance implicit is not okay

burn: that's implementation guideance, what you just said

<dlongley> +1 to implementation guidance

manu: I'm trying to figure out what the options are. You're saying you're not okay with this being implementation guidance. I'm not hearing a lot of support to put it in the spec. Which means we're headed towards a formal objection from you? Unless you say you won't formally object
... the next thing to do is to poll the group
... I don't know what the question is though
... the question has to be are we putting this PR in the spec or in implementation guidance. I think arguing over what the text meant before is futile because it's clear that it was not clear
... Right now I think some people feel that what is in there is appropriate, but not David
... there could be two polls. One of them is is the text in the spec for type appropriate as long as David's language goes in the implementation guide. I feel like that's the right balance for consensus, with the risk of David raising a formal objection because it's not strong enough from his perspective

<Zakim> burn, you wanted to poll the group

burn: I tend to agree with manu. I think that's the question. I have seen this in other groups, these disagreements, we know we're up against the wire and we need a way forward. Sometimes that's going to happen even when there are disagreements. We need to find the largest consensus
... Sometimes it goes one way and sometimes in another person's favor. I want to make sure that we understand where the group wants to go
... before I do that poll is there anyone who would like to say something?
... queue up please

TallTed: To be clear, as the text is right now, David's suggest action is perfectly viable. With the change that he wants, the other activity pattern is not viable. The way it is is flexible, the other way is rigid. The flexibility is the way to go with this spec

burn: Ted does manu's proposed poll text match what you were trying to say?

TallTed: fine by me

burn: we have tried not to do much of this in this group. Sometimes groups do a straw poll, not an official vote, but an attempt to find out the will of the group
... Let's do the poll first and we can do a proposed/resolved in a moment

<burn> POLL: The language in the VC Data Model specification with respect to types is appropriate and that is the text that should go to Proposed Recommendation. The text in PR #674 should be moved to Implementation Guidance.

<TallTed> +1

<DavidC> -1

<burn> +1

<dlongley> +1

<deiu> +1

<stonematt> +1

<manu> +1

<SercanK> +1

<ken> +1

<jonathan_holt> 0, I don't understand to consequences of implicit

burn: anyone who has an opinion chime in please
... the intent of this is to see what the will of the group is. I think we have seen that
... is there anyone else who needs to hear the answer to jonathan's statement before they can give their response?

jonathan_holt: what's the implication of having the implicit? are there any security concerns as far as.. the thought I had was in order to bootstrap the VC ecosystem you're gonna have to have claims prepared beforehand by other people. If it's not resolvable is there any risks for signing an attribute/value that you don't know the consequences are?

DavidC: this is the whole reason why I want it to be explicit on the top level type. it's because the types can be introduced implicitly which actually totally alter the meaning of the credential. A verifier who doesn't understand that implicit will be mislead.
... What I suggest is that it is a security vulnerability if you introduce a top level type which can significantly change the meaning of a VC, but you don't tell the verifier you are doing it because it's implicit. Verifiers who have done out of band communication will be fine but others will not
... Why don't we pass this to the security group and get their resolution? I'm happy to accept their assessment
... My assessment is a security vuln and that's why it must be explicit

TallTed: that vulnerability concern is 100% addressable by the policy set by the verifier. If a verifier has security concerns then they can say I will only accept strongly typed credentials. i will only accept these types. I will only accept credentials that include these properties and no others
... these are all policy questions
... there is no rule in anything we've written that says if you take a credential you must take all credentials

<yancy> +1

TallTed: none of those things are mandatory, policy handles it all

<Zakim> manu, you wanted to say and that policy is why it belongs in implementation guidance, and we really, really have to move on.

dlongley: I agree with Ted and I want to add that we already have a context field that does the mapping to the semantics of the attributes and types. You must understand the context either by reading human readable text, or by jsonld processing. You already know what those attributes map to. I disagree that the semantics are going to change. You can check the context before you look at anything else. It provides a stronger guarantee than having to check a type field

manu: I was somewhat on the fence when this text was originally introduced, and now I think it's a bad idea. I think it's important to point it out David which is why I think it should go in implementation guidance. Ted is correct this is a policy decision. If we send it to the security group that's what they're going to come back with, that's how they've found these things in the past. It depends on the risk profile of the application. The spec
... shouldn't enforce a risk policy that needs to be dynamic
... it needs to be in the implementation guidance.
... We are burning a lot of time on this
... We need to move on
... We have poll, we should make it into a proposal/resolution and move on. If there's a formal object we point back to the resolution that the group made

DavidC: no further comments.

burn: I hate to do this in the obvious absence of agreement, but we need to move forward. I'm gonna write the previous statement as a proposal. Please vote on it

<burn> PROPOSED: The language in the VC Data Model specification with respect to types is appropriate and that is the text that should go to Proposed Recommendation. The text in PR #674 should be moved to Implementation Guidance.

<TallTed> +1

<deiu> +1

<DavidC> -1

<manu> +1

<stonematt> +1

<burn> +1

<yancy> +1

<ken> +1

<dlongley> +1

<jonathan_holt> 0

<agropper> +1

<SercanK> +1

burn: we've tried to hit this as many different ways as possible, David has tried to explain as much as he can and the group is just not seeing that
... I'm going to declare that there is a decisions

RESOLUTION: The language in the VC Data Model specification with respect to types is appropriate and that is the text that should go to Proposed Recommendation. The text in PR #674 should be moved to Implementation Guidance.

burn: You may type something in the minutes if you wish David stating that you object

<manu> https://github.com/w3c/vc-data-model/pulls

manu: Those are the two PRs from today.

Issues

<manu> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Adefer

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

manu: First one is coordinate with PING, assigned to chairs

<TallTed> top to bottom sort -- https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Adefer+sort%3Acreated-asc

burn: we will close when final implementaion guide action items are completed
... ti says that already. The question is have they been completed?

ken: there's one item on the checklist and I think we'll cover it

burn: progressive trust, that's right, there's a pending pr
... we need to have the implementation guide discussion which maybe be sufficient to close it

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

manu: has to do with i81n discussion which took a month and a half but i think we have closure, the PR is merged, the 7 day close period has ended, we should close this issue
... I don't think we need a wg proposal to close that?

burn: once the group has decided to close in 7 days there's no group decision needed to close

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

manu: changing the technical report link, that happens whenever the next cr or pr is published so that's on kaz's plate

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

manu: next up is the json-ld reference, it was suggested that we update the reference to jsonld 1.1
... which was not a substantive change even though the submitter has asserted that to the TAG.
... No implementations had to change. The PR was merged
... issue should be closed to day if there's no objection from the submitter. It has been 7 days... tomorrow
... 22:32 tonight is the 7 days

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

manu: this is the clarification of json types one. This was actually a PR that brent put in that was merged
... that specifies the arity of each property
... it was non substantive, non normative, and was marked 7 day closed 9 days ago and oliver has not objected to closing

burn: done

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

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

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

burn: the chairs will be discussing these with w3m because there are ongoing frequently stated objections around these issues

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

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

manu: this one is the one brent made about type in presentation that kicked off the discussion at the beginning for this meeting. Brent raised the issue then raised his PR that addressed his issue and that was merged 9 days ago. The assertion is that brent addressed his own issue here but that kicked off another issue that david authored some text for and based on the proposal that we did today that suggestion did not make it into the spec, but brent
... addressed his concerns with the spec, therefore we should close this issue

burn: my only hesitation is that there was a change that needed to be made and it would be appropriate to say something about the change before closing it

<manu> https://github.com/w3c/vc-data-model/pull/658/commits/12681f9a24bb7669e0f23268b16ef4d318b172c2

manu: removed terms of use presentation, that was the requested change

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

manu: next up is the iat/nbf change and because the spec text was wrong it is a substantive change and we're going to discuss with w3m how to approach this today
... that is all of the issues

burn: that leaves us with 7, of which we'll probably close another today, one will happen when we go to the next version of the spec. Two real issues and 3 tracking issues
... s/Two/one
... anything else on issues?

dmitriz: no

Is doc ready for PR?

<manu> scribenick: manu

burn: Is the document ready for PR?
... We may be asked by W3M to do a single change Candidate Recommendation.
... Is there any other reason that anyone has as to why we can't publish this as a CR or a PR?

<scribe> scribenick: rhiaro

What else might block publication?

burn: this was intended to be a catchall to cover a number of the issues we have already brought up. Three tracking issues from a submitter, vague comments in general about other problems including to the TAG. We'll have to talk about the TAG discussion with w3m
... And then outstanding issue.
... Separately we know we're going to need the implementation guide. These are things that happen after the spec publication.
... Anything anyone is aware of that could block publication?
... Any other topics?

(none)

Test Suite Issues and Discussion

<burn> https://github.com/w3c/vc-test-suite/issues

<dmitriz> https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results

<manu> scribenick: manu

dmitriz: we have had a few people re run the test suite, the implementation report has been updated.

burn: Anything we can make progress on quickly?

dmitriz: Add documentation and a table of contents...

TallTed: There is one open issue, task... that dmitri said he'd take care of... change hyphen to match the doc.

dmitriz: That's still pending.

burn: I'm scrolling through this to see where we don't have at least two check marks... seeing a couple of JWT tests... bunch at end of JWT section that's untested.
... Anything else?

ken: Looks like I forgot to resubmit my tests... that may be the issue.

<dmitriz> stonematt: https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results

<inserted> manu: I double checked the test report, we have full coverage when we checked, we need to check again now that we have a new test report

ken: I'll get in the updates in quickly.

Implementation Guide

burn: Looking at implementation guide - issue #222 for the main spec, which is implementation guide issue 6.

<deiu> https://github.com/w3c/vc-imp-guide/issues/6

deiu: We have an open issue... we haven't merged yet, needs review. Renamed to a work in progress, during last call, haven't heard anything else on review.

<deiu> https://github.com/w3c/vc-imp-guide/pulls

deiu: The status of the implementation guide - we're still expecting work to be done and as soon as we have that text in the PRs, and we can review it and merge it, we have issue #14...

<burn> https://github.com/w3c/vc-imp-guide/pull/14

<deiu> https://github.com/w3c/vc-imp-guide/pull/17

<deiu> https://github.com/w3c/vc-imp-guide/pull/18

deiu: Out of all of the issues, we're waiting on input from Oliver on JWTs, we're waiting also on input from Brent... otherwise, we have other issues assigned to Dave Longley.

burn: It looks like there just needs to be work done, manu and dave, focus on 6, please.

<dlongley> https://github.com/w3c/vc-imp-guide/pull/18

dlongley: For the progressive trust PR, I did review that PR... PR #18, I'd like to get input on.... there is a PR there, good amount of text on how to create a new type of credential and how things work.

<DavidC> I will take a look at #18

<dlongley> thanks, DavidC

deiu: Even if you don't find yourself as a person that is assigned to an issue or a PR... you can still help.

<Zakim> burn, you wanted to ask what else we need for PR #14

burn: For PR #14, how many more people do we need to approve it... the text looks fairly simple, hoping to get one more person to read/approve on this call.
... That closes the main VC issue...

dmitriz: I'll volunteer to review.

TallTed: As far as the text goes, I'm fine with it, but I'm not sure how much it says about Progressive Trust.

burn: It doesn't start by saying "Progressive Trust" is "X"...
... We are out of time, thanks to all, long and challenging call, appreciate all of you sticking with it... thanks again to Manu, he does more than we know. :)
... Thanks all, talk with you all next week.

[adjourned]

Summary of Action Items

Summary of Resolutions

  1. The language in the VC Data Model specification with respect to types is appropriate and that is the text that should go to Proposed Recommendation. The text in PR #674 should be moved to Implementation Guidance.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/07/09 17:36:25 $