- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 6 Aug 2019 03:19:25 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/07/30-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Amy and Manu!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
30 Jul 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0019.html
Attendees
Present
Oliver_Terbu, Dave_Longley, Joe_Andrieu,
Dmitri_Zagidulin, Matt_Stone, Amy_Guy, Ken_Ebert,
Manu_Sporny, Andrei_Sambra, Adrian_Gropper,
Jonathan_Holt, Dan_Burnett, David_chadwick, Ned_Smith,
Benjamin_Young, Brent_Zundel, Allen_Brown,
Dudley_Collinson, Ted_Thibodeau, Yancy_Ribbens,
Justin_Richer, Sercan_Kum
Regrets
Kaz_Ashimura
Chair
Matt_Stone
Scribe
rhiaro, manu
Contents
* [3]Topics
1. [4]2nd Candidate Recommendation Publication
2. [5]Pull Requests
3. [6]Issues
4. [7]Test Suite
5. [8]General Implementation Topics
6. [9]Implementation Guide
7. [10]Use Cases
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<stonematt>
[13]https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0
019.html
[13] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0019.html
<manu> scribenick: manu
2nd Candidate Recommendation Publication
stonematt: We have something to celebrate this week... we got
to 2nd CR.
... Congratulations everyone, it's published...
... There were two caveats... with the JWT section, iss/nbf
[14]https://www.w3.org/TR/2019/CR-vc-data-model-20190725/
[14] https://www.w3.org/TR/2019/CR-vc-data-model-20190725/
stonematt: Nice job on the 2nd CR transition everyone.
jonathan_holt: Just to clarify, the problem with the issuer in
the JWT, the problem is with the iss property in the
presentation?
stonematt: Just to be clear, we processed that in the call last
week, but we called it out in the CR transition... rest of JWT
community hasn't had exposure to it, so we marked it as at
risk.
jonathan_holt: Ok, so that just didn't carry over to the JWT
section?
<rhiaro> scribe: rhiaro
Pull Requests
Pull Requests
stonematt: there is one PR out there related to terms, we've
had discussion on that
... 706
<stonematt> [15]https://github.com/w3c/vc-data-model/pull/706
[15] https://github.com/w3c/vc-data-model/pull/706
JoeAndrieu: I did get the edit in this morning that we had
talked about to clarify that it's conformant checking the proof
and checking the status
... I incorporated some feedback
... the design here is it should be editorial, clarifying
what's already stated elsewhere
... this isn't new stuff
manu: I think it's editorial and should go in the spec
... joe if it went in the spec then it resolves your concern
about the defnition?
JoeAndrieu: yeah
<manu> [16]https://github.com/w3c/vc-data-model/pull/706/files
[16] https://github.com/w3c/vc-data-model/pull/706/files
manu: then we just listen for any objections
... here are the actual changes, if you could look while we're
on the call
stonematt: not closing the queue yet if you're still reading
... I would recommend if we get agreement on the call today
we'll close it with the 7 day close?
manu: yes, I can put ap roposal in to do that
TallTed: it remains editorial, i'ts punctuation changes in the
second sentence
... semicolons instead of commas
manu: yep
JoeAndrieu: I missed that, I'll get your semicolon version in
there
stonematt: any other comments?
<manu> PROPOSAL: PR #706 addresses issue #705, which is
non-normative and editorial. Merge after further editorial
requests are made and close issue #705 after a 7 day close
period.
<TallTed> +1
<stonematt> +1
<manu> +1
<ken> +1
<deiu> +1
<brent> +1
<burn> +1
<Dudley> +1
<dlongley> +1
<bigbluehat> +1
<JoeAndrieu> +1
<oliver> +1
<jonathan_holt> +1
<agropper> +1
RESOLUTION: PR #706 addresses issue #705, which is
non-normative and editorial. Merge after further editorial
requests are made and close issue #705 after a 7 day close
period.
manu: once the updates are in the PR I'll merge
JoeAndrieu: I did the updates with the semicolons
<manu> [17]https://github.com/w3c/vc-data-model/issues/704
[17] https://github.com/w3c/vc-data-model/issues/704
Issues
<JoeAndrieu> put the "and" in
<manu> [18]https://github.com/w3c/vc-data-model/issues/704
[18] https://github.com/w3c/vc-data-model/issues/704
manu: Ted, what are your thoughts? ken brent and markus have
weighed in. Do you still want to do what we said last week or
have any of the other commnets changed the way you want to
approach this issue
TallTed: everybody is okay with a warning, I'll live with a
warning
... I think it needs to be pretty blatant and be clear that
nothing that follows should be copied and pasted because it's
gonna be bad
manu: I'm happy to take a shot at it but do you want to do the
PR? better chance we get it right if you write it
TallTed: I'll not get to it quickly, faster as a reviewer
manu: I'll put in a PR
TallTed: shouldn't take many back and forth, thanks
manu: I believe that is it
... those are the only two open issues, and all the PRs
<burn> All non-deferred issues:
[19]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+-label%3A%22defer%22
[19] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:"defer"
<manu> scribe: manu
Test Suite
<burn> [20]https://github.com/w3c/vc-test-suite/issues
[20] https://github.com/w3c/vc-test-suite/issues
dmitriz: We have one PR that came in last week relating to JWT
issue...
<dmitriz> [21]https://github.com/w3c/vc-test-suite/pull/87
[21] https://github.com/w3c/vc-test-suite/pull/87
dmitriz: Just wanted to double check w/ Brent and Oliver...
noticed back and forth conversation, looks ready to commit from
my side... ready to be pulled in?
brent: Looks good to me.
dmitriz: Ok, I will merge it.
... This does mean that, just as a heads up, the next time
libraries run the tests, other tests that haven't run yet will
show up as untested. This is a new test that has been added,
since other libs haven't run it, it'll show up as another test.
... Since this is a new test, old tests will not pass.
oliver: How do you identify these tests?
dmitriz: Based on the description.
oliver: Did you merge the PR already?
... I made two changes to the other descriptions...
dmitriz: Here's the infrastructure problem, given that we don't
have new reports coming in, you can feel free to undo the
change and we'll get that pulled in shortly.
... Most test suites, including node.js mocha, have no way to
uniquely identify tests other than description. No way to
assign unique identifier.
oliver: I've communicated with others about the new tests.
... I don't mind not changing the description...
dmitriz: Since the JWT section only affects the libraries that
support it, and the rest can mark the section unsupported.
<rhiaro> scribe: rhiaro
<Zakim> manu, you wanted to ask everyone to rerun the test
suite.
manu: we know who all the implementers are we can tell them to
rerun the test suite. We could just wipe out the old tests and
say you won't show up if you don't, so we stop getting this bad
data in the report
... it's not like we're asking a lot
<DavidC> We have rerun the test suite and it all works now
<TallTed> +1
dmitriz: that would be fantastic
<oliver_> +1
<ken> +1
<inserted> scribe: manu
stonematt: Yes, let's do that, clean it up so the final test
report looks good.
dmitriz: So, Oliver, this PR is what you want the final
descriptions to be.... right?
oliver: Yes
dmitriz: Andrei brings up a good point, when everyone reruns
the tests, please in the comments of the PR, include a link to
your implementation.
... The only way we identify the implementations, is by id of
test report, we want to provide link to repo.
oliver: What if people have private repos?
dmitriz: Then note that it's private.
stonematt: Does that mean it's just private?
dmitriz: We were encouraging everyone to rerun the test suite
anyway...
andrei: It shouldn't be mandatory for people to submit, they
should include it in email/report... we have an idea of which
repos are implementing.
<Zakim> manu, you wanted to request something post-WG of the
test suite... and sections.
<rhiaro> scribe: rhiaro
manu: +1 to andrei, this has more to do with proper messaging
around implementations. It would be good to have a link to each
implementation
... we are missing metadata for the implementations
<deiu> +1 to adding more metadata for implementations
manu: eg. what language are they in, where is the repo, who is
the maintainer, these sorts of reports typically contain all
that information. Probably the right way to do it is to in the
actual json test report have that metadata in there so we can
automatically pull it
... it's really a you can't submit a test report or running the
report fails because the metadata is not in there. dmitri it's
up to you on how to collect it, let's try to automate it vs put
in an email
<oliver_> +1 automated
manu: The second thing that typically happens, post wg, which
is important for the ecosystem after this stuff is out there.
We should have an automated test runner that runs against the
test suite. The implementation report gets wrong after a short
while, and stays wrong. We require the maintainers to provide
updated test reports but eventually they get tired of rerunning
them and stop posting new ones
... THe suggestion is to try and automate this through travis
so we have a travis build process that checks out the source,
builds it, and runs it against the tests uite for every
implementation
... so over time when people do a serach for VC libraries
through a search engine they should get a page that says here
are all the implementaitons and here is how they're doing today
based on the test suite so people can make the appropriate
judgement on what's passing
... this is a decent bit of effort but it's not insurmountable.
It's really something we should do to make sure the ecosystem
stays healthy, so we don't have to ask people to keep rerunning
things
... Two feature requests, one minor - make submitting the
metadata part of the json file. Major - lets' find a way to
configure travis so it reruns the test suite against the
implementations. It's up to the implementers to provide the
travis build script, if they don't then they won't be listed
burn: I want to remind people this is not rquired in order for
us to copmlete the process
<manu> burn: Remind people that this is not required for us to
complete the process... however, Manu is correct that this is
very beneficial to the community.
burn: its' a very beneficial thing to the community. If anyone
has any concerns now is the time to raise it
<scribe> scribe: manu
burn: If people have concerns, they should raise them now. Manu
is strongly encouraging us to consider this, but it's not
required per the W3C Process.
stonematt: Our implementation is a feature embedded in the
product, not library for consumption, how do we participate in
this in a reasonable way.
dmitriz: I can make a suggestion about that.
... I think your case falls under the rubric of "the test suite
is there to help you" rather than to inform features marked as
at risk.
... If you are not intending people to choose your library
stonematt: We want to be a part of the community that supports,
but that's part of a broader capability, not a library for
people to pick off of the shelf and go and implement.
<burn> This is supposed to be testing the spec, not a
certification test for implementations.
dmitriz: The collection of metadata, and then automate test
suite... yes, can start working on that. Step 0, while we're
building that, just drop in a link to your repo in the PR for
the test report submission. Then we'll automate it.
dmitriz asks a question.
burn: I think if no one objects, this is a good thing to do.
This is not a requirement, but please do it, that's great.
stonematt: Given the way we're planning to go to market with
this, want to be on that list.
jonathan_holt: The challenge is, it's a burden for people to
know Travis, it's an added burden.
... I guess people that want to keep it private, repo exists,
hash or verifiable credential, dogfood, it's out there, test
suite ran against it, not divulging all details.
<Zakim> manu, you wanted to suggest something that addresses
that.
<rhiaro> scribe: rhiaro
manu: there's a way to address matt and jonathan's issues...
matt's issue.. maybe it's possible for us to put a date, the
last time the thing was run, or make it so that you could have
an automated process where you do run it locally and upload it
... so basically there is a way matt for you to run this stuff
internally and continuously update that you are conformant
based on how the test suite changes. internally you're gonna
want to do that anyway. Whatever the latest test suite is
you're gonna want to make sure you're tracking
... so perhaps what we're talking about is an area where you
can upload the latest thing and based on the latest thing it
will generate the test report. i think that takes care of your
concern wher eyou're knocked off the list because you don't
have a public repo. Something to consider when putting this
together.
... The other thing, which jonathan said, it's an added burden.
I think people would help put it together. We'll do it for the
js implementation. We'll do a travis automation thing. The only
thing that ends up changing there is the build process for your
library and what you run to generate the output file. It is
probaly 3-4 lines that change in the infrastructure to do it
will just be there, DB will build the infrastructure, the only
thing that
... other people would have to do is change the 3 lines that
build their software and run the test suite
... My hope is that addresses matt's and jonnycrunch's concerns
stonematt: I think that makes sense generally
... as a point of understanding I'm assuming that if we go down
a path like this and the test suite continues to evolve oever
time to represent current thinking and evolution, that may be
coming out of the CG, we'll have a test suite for data model
1.0 and that's sort of indellible, and then there's test suite
for 1.x and that would be part of this reference for the point
of compliance where you are in the chain
... most recent test suite passed in the report?
<manu> stonematt: I think that makes sense, generally. As a
point of understanding, I expect that if we go down a path like
this, and test suite evolved over time, that may be coming out
of the CG, because the WG status is whatever it is, we will
have a test suite for data model 1.0, and that's indelible, and
then there is a test suite for 1.x to whatever, and that's a
reference for point of compliance for where you are in the
chain..
manu: in general I think that's how it would work. Keep in mind
that sometimes after you put out a REC people find corner cases
and it's appropriate to still put those corner cases in the 1.0
test suite because it shows you people implemented things
differently even though the spec said to do it in a single way
... the tests ensure that the 1.0 implementations do the right
thing for the corner cases. It's mroe continuous than that. The
spec is definitely frozen but the test suite not necessarily
because we find things after it goes out
<scribe> scribe: manu
stonematt: Ok, let's go through issues.
[22]https://github.com/w3c/vc-test-suite/issues
[22] https://github.com/w3c/vc-test-suite/issues
dmitriz: We have six issues, add features/keys/legends and
links to repos, those are in progress.
... The other three issues have to do with the context
hosting...
... Those are in process?
stonematt: Are all three of those the same thing? Waiting on
W3C to do something?
... dmitri, are you going to have time to deal w/ top 3 in your
domain?
dmitriz: Yes
stonematt: Next topic is general implementation topics
General Implementation Topics
<Zakim> manu, you wanted to mention vc tool.
<rhiaro> scribenick: rhiaro
manu: we are currently working on a general tool to issue and
verify VCs, just a commandline tool, we are planning to support
3 different keying public/private key architectures, ed25519,
the bitcoin/ethereum curve, the nsa backdoor curve... we should
be able to have that out there by next week. meant primarily to
be really simple, pick it up and use it within 5 minutes issue
your first VC and verify your first VC, using a whole bunch..
should work
... for sovrin, ethereum, btcr, veres1
... that will help people ensure there's some other
implementation they can check against
... we are looking for comments on other useful things that
tooling could do
... it doesn't support dids, it will in the future
... for right now the way it works is you generate a
public/private key pair locally, publish the key to your github
account as a gist
... then you can use that private key to issue a VC and we have
an examples directory that has 2 credentials like now that
w'ell expend to 50 in time. You can copypaste that, send it to
someone, they can verify the credential
... we only support linked data proofs
... it's an open discussion whether or not we support jwt based
proofs. We'd rather tnot but if a number of people want them we
can look into it
... the backing implementation si vc-js, it's a fully
conforming implementation
... just a heads up, hopefully that's helpful. We'd love PRs to
upgrade it, modify it
... We don't know when we're putting DID support in there,
sometime in the next couple of months
<Zakim> brent, you wanted to give aries a shout out
<manu> scribenick: manu
oliver: What if we did an implementation of JWTs?
manu: We'd pull that in, let me put you in touch with the
developers so that they can tell you where to put the PR.
<Zakim> jonathan_holt, you wanted to ask about decision logic
for JWT vs LD-sig
<brent> aries link:
[23]https://www.hyperledger.org/projects/aries
[23] https://www.hyperledger.org/projects/aries
brent: Hyperledger Aries is also doing implementations, has
strong community support, that work is ongoing...
jonathan_holt: I'm trying to figure out decision logic via JWTs
and LDP... how do I do that?
dmitriz: I suggest looking at the type... can you clarify the
question.
jonathan_holt: The VC is valid JSON, to dig into content in
JSON, to differentiate JWT vs. LDP... MIME Types might have
been helpful.
dmitriz: In that case, I'd suggest looking at the type... JWT
documents require ...
oliver: At which point do you want to make the decision? When
you receive it, or when you decode the base64 blob?
jonathan_holt: If it's base64, I'm assuming it's base64.
oliver: A JWT must have 'vc' or 'vp' attribute.
... The header might contain a type field...
... Checking the 'vp' property is one way, we can chat about
this during next chat.
<Zakim> manu, you wanted to "content sniffing"
<rhiaro> scribenick: rhiaro
manu: we don't have mime types we can depend on yet, w're
talking about content sniffing. You can't always trust the mime
type. You have to back off to doing content sniffing. If you
get a giant base64 encoded blob it's almost certainly not
json-ld
... but to be safe you need to run a whole bunch of other
things to make sure that you're correct
... for example I dont' think the top level jwt has an
@context, json-ld must have an @context. You can sniff for
@context, sniff for vc or vp existing, and if your eally want
to be sure sniff for other things in a jwt like iss, jti,
things of that nature. If you see those things and no @context
you know it's a jwt
<oliver_> +1 @context sniffing
manu: this is something we shoould put into the implementation
guidence
... let's make sure we put this in the implementation guidence
... how do you tell a vc that's encoded as a jwt vs one that's
ldproofs or json-ld
... in general you should be safe by just sniffing for
@context. Ifthat doesn't exist search for vc and vp, and if
those do exist it's almost certainly a VC encoded as JWT
jonathan_holt: context is still required isn't it?
oliver_: but the context in a jwt is not at the top level, it's
inside the vc or vp attribute
<manu> oliver: @context is not at the top in a JWT...
oliver_: base64 encoded header . payload . signature should be
enough to distinguish between ldproofs and jwt specific ones
... the compact serialisation is really specific to jwt
<manu> oliver: You could just detect compact serialization.
manu: 99.99999% of the time I think that's true, I'm concerned
about people encoding ... base64 does not include the .
character.. so I'd be concerned about if someoen invented their
own encoding mechanism and used . for separaters and based64
encoded a bunch of information with .s and it wasn't a jwt,
then the library would misunderstand that
... that's the only thing that's giving me heartburn, that
would happen in the worst case, the lib passes all the test
suites and everything then it's in production and it chokes on
some data. It feels like a potential attack vector
... I'd rather operate on the base64 decoded data. Once you're
out of base64 land there is some semantics and structure to the
data you're expecting so at that point check @context, check
the types, there are long series of checks you can od at that
point. There more checks you do the more sure you can be it's a
jwt or a jsonld document
... I'd suggest not doing the base64 detection thing but
decoding then operating whatever checks on the decoded
information
jonathan_holt: cool, that's what I'm doing, on course
<manu> jonathan_holt: Ok, cool, that's what I'm doing...
thanks.
Implementation Guide
<manu> scribenick: manu
<stonematt> [24]https://github.com/w3c/vc-imp-guide
[24] https://github.com/w3c/vc-imp-guide
<deiu> [25]https://github.com/w3c/vc-imp-guide/pulls
[25] https://github.com/w3c/vc-imp-guide/pulls
<deiu> [26]https://github.com/w3c/vc-imp-guide/pull/21
[26] https://github.com/w3c/vc-imp-guide/pull/21
deiu: Short section on test suite and implementation report,
links to those resources.
... approved by ted/brent, let's merge right now, any
objections?
manu: +1 to merge
deiu: Merging.
<deiu> [27]https://github.com/w3c/vc-imp-guide/pull/17
[27] https://github.com/w3c/vc-imp-guide/pull/17
deiu: We have PR #17, JSON Schema for VC...
... I don't have an opinion on this...
... I'll review...
<deiu> [28]https://github.com/w3c/vc-imp-guide/pull/18
[28] https://github.com/w3c/vc-imp-guide/pull/18
jonathan_holt: Work in progress... will work on it.
deiu: If you're happy with the changes, we can merge.
... We only need two reviewers... can we ask DavidC to take a
look at it?
<deiu> [29]https://github.com/w3c/vc-imp-guide/pull/19
[29] https://github.com/w3c/vc-imp-guide/pull/19
<DavidC> Sorry I cannot connect voice today (as I am using my
mobile phone)
<DavidC> which one do you want me to review 19 or 18
<rhiaro> scribenick: rhiaro
manu: what may be coming is a set of counter arguements. Each
group should make the arguement for the proof mechanism in the
way they want, and another section which potentially (may be a
terrible idea) goes through the counter arguements for the
other section. Then we have all the argeuemetnsf or and against
documented. The way it is done now is it muddies who is arguing
for what
... I do'nt think it's a big deal, just a matter of keeping the
sections separate and keeping the arguements separate so people
can revise and make things more accurate
... I think we'll go back and forth a couple of times over a
month and come to a resolution
<manu> scribenick: manu
stonematt: Andrei, just for the group, that was our decision in
Barcelona, have different sections, our expectation is that
they're standalone sections.
<brent> +1
<deiu> [30]https://github.com/w3c/vc-imp-guide/issues
[30] https://github.com/w3c/vc-imp-guide/issues
andrei: We have a few issues I'd like to discuss... nothing has
changed since last time we brought this up... dlongley is
assigned to a bunch of issues... I guess, as long as we don't
see PRs, there isn't a lot to discuss.
... We'll just wait for PRs to be opened.
dlongley: Some time might clear up next week to get to them,
just status report, all these people are really busy.
andrei: Yes, understandable, and that's it.
Use Cases
stonematt: Anything we want to say here, Joe?
<DavidC> I will review
[31]https://github.com/w3c/vc-imp-guide/pull/18 and give you my
comments. Will take a few days though. My first task is to
write a VC profile for mobile driving licenses
[31] https://github.com/w3c/vc-imp-guide/pull/18
JoeAndrieu: Obviously, we're winding down the work here...
there is a delicate balance between add new stuff and just wrap
it up, please get your comments in so we can get them
incorporated in most effective way.
<DavidC> Mobile driving licenses profile will suggest JWT as
the ISO draft already uses JWT
ken: Ned and I have put together some use cases for IoT type
devices, they need to be modified to fit style/direction for
use case document, would like to see 1-2 examples that meets w/
community approval. We can get that in some time this week.
JoeAndrieu: Ok, we will look for that.
stonematt: DavidC, are you going to provide input on Use Cases?
<DavidC> I was not proposing to provide any input on use cases
burn: Please work on implementation guide!
stonematt: Thanks everyone!
Summary of Action Items
Summary of Resolutions
1. [32]PR #706 addresses issue #705, which is non-normative
and editorial. Merge after further editorial requests are
made and close issue #705 after a 7 day close period.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [33]scribe.perl version
1.152 ([34]CVS log)
$Date: 2019/08/05 18:18:45 $
[33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[34] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 5 August 2019 18:20:30 UTC