scribenick: manu
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
<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.
<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
<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
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)
<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.
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]