- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 25 Jun 2019 15:37:04 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/06/18-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Dave and Amy!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
18 Jun 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jun/0007.html
Attendees
Present
Amy_Guy, Andrei_Sambra, Brent_Zundel, Dave_Longley,
Justin_Richer, Kaz_Ashimura, Ken_Ebert, Matt_Stone,
Sercan_Kum, Ted_Thibodeau, David_Chadwick,
Markus_Sabadello, Jonathan_Holt, Ned_smith,
Dmitri_Zagidulin, Oliver_Terbu
Regrets
Tzviya_Siegman, Charles_McCathie_Nevile, Yancy_Ribbens
Chair
Matt_Stone
Scribe
dlongley, rhiaro
Contents
* [3]Topics
1. [4]Test Suite
2. [5]Implementations
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<scribe> scribe: dlongley
stonematt: We've been going through PRs top to bottom and Manu
as editor has been driving much of that discussion. He's not on
the call today. How should we proceed? We have the standing
agenda PR and lightning around issues/test suite discussion and
discussion on implementation.
... But given our attendance today, is that still the right
order?
oliver: I provided the PR for the JWT tests and considering
that our plan is to go from CR to PR next week, I believe, to
give implementers a chance to submit test reports I would like
us to cover the PR for the JWT test suites.
... I don't know if it's already sufficient to submit tests.
scribenick: rhiaro
dlongley: second that, there's a related issue to do with jwt
claims and issuance date so we should talk through that and
make sure the test suite is doing what we want and people hvae
time to write tests for it
... there's another issue, not sure if it would benefit us
talking about it - ted and david c were having a discussion on
github, to do with type
scribenick: dlongley
stonematt: Ok we can start with those. Let's start with the JWT
PR.
<ken> [8]https://github.com/w3c/vc-test-suite/pull/50
[8] https://github.com/w3c/vc-test-suite/pull/50
scribenick: rhiaro
dlongley: oliver, have you been following the discussion around
using the nbf jwt claims instead of the iat jwt claims to
represent issuance date?
<TallTed> [9]https://github.com/w3c/vc-data-model/pull/646
[9] https://github.com/w3c/vc-data-model/pull/646
oliver: I'm aware but don't think we came to a conlusion yet.
My personal opinion is we won't change it
dlongley: the issue is the semantics for issuance date are
ffectively this credential cannot be used before this time,
it's not valid before this date and time, we chose a bad name
for that, we intend to switch it for something like validFrom.
The semantics in the spec are this credential is not valid
before this time. jwt claim the best match for that is abf not
iap. we have in the spec today a conflict, the issuance date
says the semantics are not
... valid before this date, the jwt says use the iat claim
instead of the nbf claim. we need to resolve that
... the better way to resolve that despite the poor name is to
use the nbf claim for jwts because the group agrees moving
forward in the future we'll deprecate issuance date in favour
of validFrom
... that would also map to nbf
scribenick: dlongley
<DavidC> +1
oliver: Is the idea that `iat` won't be used in the future?
It's still a common claim in the future.
<rhiaro> dlongley: jwt users could still use it. We reserved a
term called issued because that was better. We reserved it in
the context but we can't say anything about it normatively. In
the future you could map issued to iat. You could also use iat
independantly in your jwt but it wouldn't have any fields, you
could map it but we can't say anything normative about that
oliver: Then I would be ok with the changes. What should be
changed in the spec? Is it possible to use informative language
to that?
<Zakim> dlongley, you wanted to answer and to
scribenick: rhiaro
dlongley: we have a conflict in the spec we have to clarify.
This is a clarification change that does not cause another CR.
the change is to say we have that conflict, issuanceDate has
certain semantics which were in conflict with us using the iat
claim and w eshould have used the nbf claim. Youc ould submit a
PR and the group could have a resolution to change to nbf and
that would solve the problem
scribenick: dlongley
oliver: In that case, I will change my tests to do this. If the
group agrees to use `nbf` instead of `iat` and implementers can
assume to test against `nbf`.
scribenick: rhiaro
dlongley: we should get a resolution on the call today so
everyone knows that
scribenick: dlongley
`issuanceDate`
<TallTed> PROPOSED: Change spec text mapping of issuanceDate to
use JWT nbf claim (with matching semantics) instead of JWT iat
claim (with conflicting semantics), in parallel to testsuite
change to match
<DavidC> +1
<dlongley> +1
<TallTed> +1
<ken> +1
<deiu> +1
oliver +1
<stonematt> +1
oliver: I'm fine with that. Can we merge the PR this week?
<stonematt> No ojections
RESOLUTION: Change spec text mapping of issuanceDate to use JWT
nbf claim (with matching semantics) instead of JWT iat claim
(with conflicting semantics), in parallel to testsuite change
to match
TallTed: The PR should be mergable this week with the necessary
change.
DavidC: Oliver already knows this -- we are this week testing
the JWT signatures and we hope to have a conformant
implementation by the end of the week.
stonematt: Excellent. So David you'll have the test report in?
DavidC: Yes, I just emailed Oliver, working on it.
stonematt: We need to pull in both PR #50 from the test suite
when ready.
oliver: I will try to do it today because it's just replacing
`iat` with `nbf`. And then just need someone to merge them this
week.
codenamedmitri: I will merge the PR.
stonematt: These changes are to the test suite and is there a
similar change and new PR in the data model for this?
oliver: I'm not aware of any, so I will have to create a new
one tomorrow.
TallTed: There is a PR for this change, it needs more massage
but it will be based on this resolution, PR #646 on the data
model.
[10]https://github.com/w3c/vc-data-model/pull/646
[10] https://github.com/w3c/vc-data-model/pull/646
<TallTed> PROPOSED: Change spec text mapping of issuanceDate to
use JWT nbf claim (with matching semantics) instead of JWT iat
claim (with conflicting semantics)
([11]https://github.com/w3c/vc-data-model/pull/646), in
parallel to testsuite change to match
([12]https://github.com/w3c/vc-test-suite/pull/50)
[11] https://github.com/w3c/vc-data-model/pull/646
[12] https://github.com/w3c/vc-test-suite/pull/50
stonematt: any objections?
oliver: One question -- I don't have any objections, it makes
sense. Are you doing the PR for the data model then?
TallTed: You can comment on that PR. I think we all understand
what has to happen.
stonematt: Who is doing the typing?
oliver: I will go to the github repo and make a comment on that
PR.
RESOLUTION: Change spec text mapping of issuanceDate to use JWT
nbf claim (with matching semantics) instead of JWT iat claim
(with conflicting semantics)
([13]https://github.com/w3c/vc-data-model/pull/646), in
parallel to testsuite change to match
([14]https://github.com/w3c/vc-test-suite/pull/50)
[13] https://github.com/w3c/vc-data-model/pull/646
[14] https://github.com/w3c/vc-test-suite/pull/50
DavidC: I have some good news to report, I'm at the EEMA conf
on Identity, I brought up VCs here and I've added Infocert on
line 16 on the implementer spreadsheet and they will fill out
the columns they are implementing and I've referred them to the
test suite which they are going to do as well.
<rhiaro> dlongley: manu is the author of the data model PR and
he is away this week. If we want to get this moved ahead I
don't think a comment on the PR will work. We might want to
merge the PR as is and have oliver or tallted or whoever will
do the text to change the claim name as a separate PR
oliver: The idea is to get Manu's PR merged first and then
replace `iat` with `nbf`.
<rhiaro> dlongley: yes that's the plan
<rhiaro> ... and 646 is merged
<DavidC> @dlongley EU conf -> EEMA conf
stonematt: Is the next discussion is about types.
DavidC: I have a couple of issues about testing. The not
transferable property ... I'm not sure there's a test for that.
Anything that doesn't get two implementers will be removed, but
there's no test at all.
... I put in an issue for the refresh service because it's a
backdoor for the verifier to talk with the issuer.
... If we accept the refresh service in the VP but not in the
VC it removes the backdoor.
stonematt: Test suite agenda item is coming up later.
<TallTed>
[15]https://www.w3.org/2019/06/11-vcwg-minutes.html#resolution0
2
[15] https://www.w3.org/2019/06/11-vcwg-minutes.html#resolution02
DavidC: I think there's new information.
TallTed: Not to be too blunt but I think you disagree with the
conclusion, but if you have new evidence you should present
that.
DavidC: The new evidence is to go back to the minutes where
strong typing was required.
... So all we need to do is clarify what associated meant but
we've changed conformance from a MUST to a MAY.
TallTed: I have not found those minutes and I have been
looking.
DavidC: At the time I believe Ken was arguing for it with me,
but I don't know if he can recall that.
ack
ken: I believe that I had questions about whether it was
supposed to be that way. I don't think I had a clear
understanding of it either way.
brent: I just want to say that this is my PR, the text in the
PR is my understanding of how the associated types ought to be
interpreted and that understanding was agreed to by everyone on
the call last week, the only one I know that disagrees with
that interpretation is David.
DavidC: That is because changing strongly typed to implicit and
it's totally different now from what it was before. Having any
statement on type is now MAY not MUST. Once you've gone from
strong typing to implicit typing you've totally changed it.
TallTed: There is nothing that prevents you as a verifier to
require strong typing.
DavidC: As the test was originally it prevented implicit
typing.
TallTed: I disagree and understand that's your interpretation
but no one agrees with that.
DavidC: That was Brent's original understanding.
brent: That was my original understanding but I've changed my
opinion.
DavidC: If we're changing from explicit typing to implicit
typing we need another CR.
TallTed: But the words as they were written do not have
different meaning from how they are being revised.
... We are not changing the words meaning.
DavidC: Yes we are.
TallTed: We are not changing the meaning of what was there
before but you didn't think it meant that, but everyone else
concurred that the meaning is what stands today.
... The wording as it stands is what this is based on.
DavidC: New text about implicit types wasn't there before.
TallTed: That is your flawed interpretation.
ken: I wanted to say that in the test suite I couldn't
determine whether or not a subtype was required. I was seeking
clarification about that and that came last week, and it was
around the presentation. There was no ambiguity around the VC
then we had the discussion and agreed with the group.
DavidC: I also agree with that.
TallTed: That's not what the text has been.
brent: I wanted to second what Ken was saying ... which is that
one interpretation of the text was that a VP needed an
additional subtype so in order to clarify that's not the case
we needed to make it more clear that implicit typing was
allowed. I believe everyone in the group understood it that
way. The fact that we're having this back and forth shows that
the current text isn't clear.
... What my PR does is add the line that makes that
clarification according to the consensus of the group. I
understand David that you disagree with that, the question is,
do you formally oppose it?
DavidC: Yes I do.
... The clarification was needed for the VP it was to say that
the type was not needed.
TallTed: You're still not referencing the actual paragraph
which talks about all three things, VPs, VCs, embedded objects
therein.
... It is not explicitly about VPs/VCs, it's to all three
things. You can formally object to the resolution and the spec
as it stands. But right now the text says what it does.
... Lots of people have read it and understood it to be
basically as I have said. You are the only person that has had
a different interpretation.
DavidC: I'm sorry, I'm not, Brent was the same as me but was
persuaded to change.
TallTed: Fine, Brent changed that position to my understanding.
I don't believe we'll come to resolution on this on this call.
DavidC: I did propose a resolution.
TallTed: But it would trigger a new CR.
DavidC: We've added new terms before, I don't see it as a lock
up.
TallTed: I'm sorry you don't see it, but you're incorrect
again. I don't think we'll come to resolution on this on the
call.
stonematt: I agree, I think David if you want to object to the
resolution we can do that with email or a sideline call with
Burnett/Manu.
DavidC: If you give me advice then I'll follow it, thank you.
stonematt: I'll follow up on that.
... Next order of business ... are there any other issues we
need to cover today?
Test Suite
dmitri: In the test suite we have no new issues. We have one
that should be closed because it was addressed by last week's
PR that was merged. We have two new PRs.
... The JWT one and that's waiting for the corresponding change
in the data model and another PR that is just an implementation
report by Yancy.
... It sounds like we merge it -- it's just an implementation
report.
<dlongley> +1
<TallTed> +1
<stonematt> +1
dmitri: Issue #47
([16]https://github.com/w3c/vc-test-suite/issues/47) should be
resolved.
[16] https://github.com/w3c/vc-test-suite/issues/47
<dmitriz> propose close:
[17]https://github.com/w3c/vc-test-suite/issues/47
[17] https://github.com/w3c/vc-test-suite/issues/47
<ken> +1 to close #47
<stonematt> +1
<dlongley> +1
<brent> +1
<dmitriz> Yancy's implementation report:
[18]https://github.com/w3c/vc-test-suite/pull/49
[18] https://github.com/w3c/vc-test-suite/pull/49
<TallTed> +1 close #47 as addressed y #48
<ken> +1
<dlongley> +1 to merge 49
<stonematt> +1
dmitri: So that's it for the moment.
stonematt: DavidC you had some questions/discussion.
DavidC: Two issues. One was the "not transferable" flag. If
there isn't a test for it.
dmitri: This is complex human social interaction/not testable.
<rhiaro> not tested != not implemented
stonematt: One of things we've said from the beginning -- if an
implementer supports that they will support it then that's
evidence for keeping it in the specification.
... In the cases that there's a not an obvious test that
doesn't necessarily mean that it has to go away.
<brent> just because something is not automatically testable,
or is difficult to automatically test, doesn't mean it can't be
normative in the spec.
DavidC: We could separate testing refresh service for VPs vs.
VCs -- so we could just have support for VPs and not for VCs
based on implementer feedback.
dmitri: Yes to the separation, two different sections for VPs
vs. VCs.
DavidC: If we can make it two columns in the table; at the
moment, if people just implement it in VPs and not in VCs then
we could remove it from VCs -- that would be the reason for
removing it. People could then say they support one way and not
the other.
dmitri: Any objections for changing the implementation report
so we have two columns for that?
stonematt: Without endorsing -- not considering the downstream
issues, I don't object to that change.
ken: I don't object either, but I still don't know how to
report "not implemented" because it still shows as failing
instead.
dmitri: I believe the test reports have three states: pass,
fail, and skip. And "skip" is did not implement.
ken: In the automated test report that is generated do I need
to put that?
dmitri: I don't think so? On the vc-js test suite in the
generated HTML for the test report, it's a red X for fail,
green check for pass, and yellow dash for not implemented.
... I can follow up with you offline.
ken: You can follow up with my offline and give guidance.
dmitri: No problem.
brent: I don't know what Dmitri's talking about either possibly
because the generated HTML doesn't work for me.
dmitri: Understood, let's connect after this -- I'll link to
the HTML ones so you can see.
<dmitriz>
[19]https://w3c.github.io/vc-test-suite/implementations/#confor
mance-testing-results
[19] https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results
brent: But those are just for when there are no tests, right?
TallTed: Fake bad/fake good is a problem here.
dmitri: That got resolved, fake good/bad needs to be updated.
brent: I'm assuming the other implementations will each have a
column as well.
... I can't speak to the accuracy of this without getting a
column for my implementation.
dmitri: I'm going to open an issue to do several things. We
need to connect with you afterwards.
<dmitriz> need to connect with brent to resolve the html
generation issue
brent: We do have issue 30 that's related to this.
<dmitriz> yes, ok.
<dmitriz> ok, so, going back up the conversation stack -
<stonematt> [20]https://github.com/w3c/vc-test-suite/issues/30
[20] https://github.com/w3c/vc-test-suite/issues/30
dmitri: I think the action items are to clarify in the README
and the UI how to distinguish fail from "not tested".
... (not implemented) vs. there is no test for it
brent: We'll need to take it offline and sort through this.
dmitri: Sounds good.
<ken> I would like to be in the offline call too @dmitri
stonematt: Any other issues with the test suite today that
require discussion?
Oliver: Maybe one short question, related ... the `nbf` field
and the `issuanceDate` field are both mandatory, right?
dlongley: The `issuanceDate` is mandatory in the spec.
... There is a reserved `issued` field that we can't make
mandatory without going back into CR.
Oliver: Ok, got it.
stonematt: Does that meet your needs, Oliver?
Oliver: For now, definitely, once we have our spec we'll keep
working on it and we should solve around `issued`.
... It's odd to have a JWT without `iat` but with `nbf`, but
that's fine.
stonematt: In the implementation guide we can say that `iat` is
recommended in there but not called out in the data model as a
formality.
Oliver: We should add this to the implementation guide. If we
talk about this `issued` field we should also talk baout `iat`.
<rhiaro> dlongley: +1 we sholud mention in the implementation
guide even though it's not normative in the spec, it's best
practice
<ken> Thanks to dmitri for building and improving the test
suite.
<stonematt> +1
<TallTed> +1 add `issued` property and JWT iat mapping to
implementation guide
<dlongley> +1
Implementations
stonematt: Where are we with implementations, who is working on
them, what issues are we finding, open floor, please use the
queue.
ken: Our rust implementation seems to be pretty stable in terms
of getting through all the test suite issues we chose to get
through, we have three things we chose not to implement and now
we're just keeping current with minor changes to the test suite
as it gets updated.
stonematt: I'm looking at who has submitted implementation
reports.
ken: I've submitted one for the Rust Sovrin implementation.
dmitri: There is also the Evernym implementation report, one
from Yancy, one pending from Oliver.
Oliver: I know that Markus Sabadello is working on one and will
submit an implementation this week.
<stonematt>
[21]https://github.com/w3c/vc-test-suite/tree/gh-pages/implemen
tations
[21] https://github.com/w3c/vc-test-suite/tree/gh-pages/implementations
Markus: This is Markus from Danube Tech we worked on an
implementation last year using Java, including LD proofs and we
updated it last week and expanded it to also support JWT
proofs.
markus_sabadello: Still a lot of failures but ok to submit the
report and update it later.
stonematt: What's the process for submitting?
<DavidC> I have to go now. But I have found the minutes where
type was discussed, and in this @tallted was arguing for
explicit typing quote "<TallTed> Implicit typing mandates
inference/reasoning in tools that consume the data. Explicit
typing lowers the bar for verifying, etc. I believe there are
other reasons to encourage explicit typing; the only reason I
know of to discourage explicit typing is the "extra" triple."
<DavidC> [22]https://www.w3.org/2018/06/19-vcwg-minutes.html
[22] https://www.w3.org/2018/06/19-vcwg-minutes.html
dmitri: Just another PR, I would highly encourage everyone to
submit in progress reports as well.
markus_sabadello: Thank you.
<markus_sabadello> work-in-progress implementation by Danube
Tech:
[23]https://github.com/danubetech/verifiable-credentials-java
[23] https://github.com/danubetech/verifiable-credentials-java
stonematt: Any other comments?
... Any other topics to cover today? We have extra time.
<ken> a+
ken: I had one PR that was in the implementation guide that I
think could be merged. I don't know if we have any time to go
over other PRs in the implementation guide.
<ken> [24]https://github.com/w3c/vc-imp-guide/pull/12
[24] https://github.com/w3c/vc-imp-guide/pull/12
<stonematt> who is nms in Webex?
ken: I put together a PR for the benefits of ZKP proofs and it
was reviewed by Ted and Brent, it's awaiting merge.
... I don't think it's controversial.
stonematt: Any objections to pulling this one in?
no objections
ken: Thank you.
stonematt: Do we need a resolution?
<stonematt> ACTION: merge pr#12 in implementation guide:
[25]https://github.com/w3c/vc-imp-guide/pull/12
[25] https://github.com/w3c/vc-imp-guide/pull/12
ken: We haven't been doing those for the implementation guide.
But it hasn't gotten much attention in the last six weeks.
stonematt: Any other issues or topics in the implementation
guide to cover?
... There are 9 open issues and 6 open PRs.
<stonematt> [26]https://github.com/w3c/vc-imp-guide/pull/7
[26] https://github.com/w3c/vc-imp-guide/pull/7
stonematt: Is this ready for review?
deiu: I think it was.
stonematt: I will follow up on that, I can't add reviewers.
<stonematt> ACTION: follow upon PR7
[27]https://github.com/w3c/vc-imp-guide/pull/7 -- needs
review/approve cycle
[27] https://github.com/w3c/vc-imp-guide/pull/7
deiu: I can try to rebase it.
stonematt: Thank you.
... There's a call to action for the participants here, please
go take a look at that.
<stonematt> [28]https://github.com/w3c/vc-imp-guide/pull/11
[28] https://github.com/w3c/vc-imp-guide/pull/11
stonematt: any objections to pulling that one in?
<stonematt> ACTION: merge
[29]https://github.com/w3c/vc-imp-guide/pull/11
[29] https://github.com/w3c/vc-imp-guide/pull/11
none
stonematt: We have a couple of issues here from our F2F, I'm
looking at ... one that Brent, you're assigned.
<stonematt> [30]https://github.com/w3c/vc-imp-guide/issues/6
[30] https://github.com/w3c/vc-imp-guide/issues/6
brent: I have most of a PR written, just languished as I'm
doing test suite stuff.
<stonematt> [31]https://github.com/w3c/vc-imp-guide/issues/4
[31] https://github.com/w3c/vc-imp-guide/issues/4
scribenick: rhiaro
dlongley: on my radar now.. will be a while, i have 2 issues
assigned to me
scribenick: dlongley
stonematt: Anything else today?
... Ok, we're done with the call, thanks everyone.
<stonematt> good bye all!
<ken> Thanks, matt
<James_Dz> James M Dzierzanowski, Kaiser Permanente (New
Person)
Summary of Action Items
[NEW] ACTION: follow upon PR7
https://github.com/w3c/vc-imp-guide/pull/7 -- needs
review/approve cycle
[NEW] ACTION: merge https://github.com/w3c/vc-imp-guide/pull/11
[NEW] ACTION: merge pr#12 in implementation guide:
https://github.com/w3c/vc-imp-guide/pull/12
Summary of Resolutions
1. [32]Change spec text mapping of issuanceDate to use JWT nbf
claim (with matching semantics) instead of JWT iat claim
(with conflicting semantics), in parallel to testsuite
change to match
2. [33]Change spec text mapping of issuanceDate to use JWT nbf
claim (with matching semantics) instead of JWT iat claim
(with conflicting semantics)
(https://github.com/w3c/vc-data-model/pull/646), in
parallel to testsuite change to match
(https://github.com/w3c/vc-test-suite/pull/50)
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [34]scribe.perl version 1.154 ([35]CVS log)
$Date: 2019/06/25 06:36:02 $
[34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[35] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 25 June 2019 06:38:10 UTC