- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 17 Jun 2019 20:19:23 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/06/11-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Brent, Manu and Benjamin!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
11 Jun 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jun/0004.html
Attendees
Present
Allen_Brown, Andrei_Sambra, Brent_Zundel, Dan_Burnett,
Dave_Longley, Dmitri_Zagidulin, Ganesh_Annan, Jack_Busa,
Justin_Richer, Ken_Ebert, Manu_Sporny, Sercan_Kum,
Ted_Thibodeau, Adrian_Gropper, Jonathan_Holt,
Oliver_Terbu, Yancy_Ribbens, Benjamin_Young,
Kaz_Ashimura, Markus_Sabadello
Regrets
tzviya, Amy_Guy
Chair
Dan_Burnett
Scribe
Brent, Manu, Benjamin
Contents
* [3]Topics
1. [4]Describe plan for the call
2. [5]https://github.com/w3c/vc-data-model/pulls
3. [6]PRs
4. [7]PR announcements
5. [8]We have so many issues
6. [9]Test Suite Issues and Discussion
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
Describe plan for the call
<brent> scribenick: brent
burn: first PRs, then closing issues, then test suite, then
implementation topics
... anything else that should be added?
[12]https://github.com/w3c/vc-data-model/pulls
[12] https://github.com/w3c/vc-data-model/pulls
PRs
PR announcements
manu: good news, thanks to everyone who puts in PRs. Brent,
Ken, David, Ted.
<manu> [13]https://github.com/w3c/vc-data-model/pull/641
[13] https://github.com/w3c/vc-data-model/pull/641
manu: 641 is first up.
<Justin_R> I would call in but I don't have the new meeting
info.
manu: internationalization has been re-written 5 times now
<Justin_R> So if anyone can help with that, please DM me
manu: many other groups are chiming in, separate calls are
happening
... we believe we have a proposal. It may not actually be a
needed solution.
... we are getting mixed signals
... we may end up pointing to the string meta specification
... the current PR is where the discussion is now..
... if it changes again it will simply point to string meta.
... if no progress is made, it will be revised.
ken: ripped out all the french language examples?
manu: yes, because we did that wrong
... no markup in the data, it is a attack vector
... instead we will write an example that shows how to use a
language tag.
... we will put some language examples back, but can't do
directionality.
ken: should we make corresponding changes to the test suite?
manu: yes
... unfortunately now we are the "stuckee" for language
direction on the internet.
<manu> [14]https://github.com/w3c/vc-data-model/pull/646
[14] https://github.com/w3c/vc-data-model/pull/646
manu: 646, validFrom and validUntil. Looking for re-review
after changes.
... the problem is that issuanceDate is different from
validFrom and maps to different things in JWT.
... so mapping it to something different may be a normative
change.
... this PR doesn't make changes to the JWT section, it only
says that these terms are going to be used in the future.
... take a look at 646
dlongley: Ted was recommending adding non-normative text to the
JWT section.
... add validFrom in the future and have it map to something
else.
... validFrom and issuanceDate are different.
manu: example is digital coupons
<Zakim> burn, you wanted to ask about validFrom
burn: is there a situation where someone would want to use
validFrom as a date before it was issued?
manu: potentially
burn: even though it was issued when I was 16, it was valid
from when I was born
dlongley: yes, this PR brings up the fact that they have
different meaning.
... if you only had issuanceDate, then the credential can't be
valid before that date.
manu: please comment on the PR
<manu> [15]https://github.com/w3c/vc-data-model/pull/652
[15] https://github.com/w3c/vc-data-model/pull/652
manu: 652 is up next
... Tony said JWS is a proof mechanism, JWT needs to be there
as well. It has gone back and forth.
... some things are standardized, some are not. Asked for
re-review from Tony.
... expect he will want a stronger statement about what is a
standard or not.
... giving that treatment for everything in the text would add
alot of stuff.
... suggestion is to go with the modified text.
... would like to hear is there are objections?
... not hearing any, do we need a resolution?
burn: it would be good to do that. that can be dropped in to
say what the WG has confirmed.
<manu> PROPOSAL: The Working Group has confirmed that calling
out the phase of standardization that any particular
specification is in is not necessary as implementers can
determine that information from the heading information in each
specification as well as perusing the normative and
non-normative reference section.
manu: any objections?
ken: it doesn't actually reference which one we're talking
about.
manu: it shouldn't matter, this is general
RESOLUTION: The Working Group has confirmed that calling out
the phase of standardization that any particular specification
is in is not necessary as implementers can determine that
information from the heading information in each specification
as well as perusing the normative and non-normative reference
section.
burn: no objections
manu: please review the PR
<manu> [16]https://github.com/w3c/vc-data-model/pull/663
[16] https://github.com/w3c/vc-data-model/pull/663
manu: Ted did a new PR, 663
... this is editorial
<manu> [17]https://github.com/w3c/vc-data-model/pull/658
[17] https://github.com/w3c/vc-data-model/pull/658
<manu> scribe: manu
brent: PR 658 was in response to issue 653, and issues 653 came
up during a WG conversation... basically, the question was "how
many types must a presentation have?"
... Some of the language in the next makes it suggest that you
have to have at least two... my initial reading of the text was
opposed to others reading of the text...
... two sides seem to be -- type needs to be explicit and
always mentioned in the type field, or type out to be implicit
and should be allowed, properties not described by any type
anywhere, then they need to be undrestood by verifier, or
rejected because they are not understood, but should be allowed
by the spec.
... That's my understanding of the two sides of the argument,
we need the group to weight in on what should go into the spec.
<inserted> scribenick: brent
manu: David is arguing from a strong typing argument. Try to
list a type, some are mandatory. The compromise was that some
must be mandatory.
... in presentation, it doesn't make sense to require two
types.
... it can be done, but I feel it goes too far to require it.
... I know David wants that, but I don't think it should.
... we were fine with duck-typing, nothing breaks if you don't
specify the type.
... the compromise was to help JSON developers.
... linked data community has never done.
<manu> brent: My $0.02 is in the PR, I think that's what it
should say.
manu: is anyone supporting David's positional at this point?
... he isn't on the call, but no one is supporting the opinion
that type is mandatory.
burn: I want that in the minutes, there is no support for
David's opinion
ken: Is removal of sub-typing applicable to only the
presentation, or to both?
manu: we can't change anything normative.
... we say it must be associated with a more narrow type.
dlongley: this debate has been about defining "be associated
with"
... do those need to be explicit?
... This PR clarifies that.
<manu> [18]https://github.com/w3c/vc-data-model/pull/658/files
[18] https://github.com/w3c/vc-data-model/pull/658/files
manu: I want a resolution on this, everybody please go to the
link and read it.
... I think the spec text is fine, minus the added
termsOfUsePResentation
brent: I can remove that.
manu: would anyone object to David's idea?
... digital bazaar objects
oliver: I also object
ken: As do I
brent: me too
manu: any other strong feelings?
<manu> PROPOSAL: Merge PR 658 as it reflects the consensus of
the Working Group. Specifically, more organizations would
object to more stringent type requirements than what exists in
PR 658.
manu: any objections?
burn: no objections
RESOLUTION: Merge PR 658 as it reflects the consensus of the
Working Group. Specifically, more organizations would object to
more stringent type requirements than what exists in PR 658.
manu: I'll merge that as soon as Brent makes the minor change
burn: that resolution only applies after a change has been
made.
We have so many issues
manu: the good news, we have a pretty good handle on them
... we are getting PRs.
... I think we're done with the spec. we need folks to do a
read of the whole thing.
... need to get the internationalization in. The rest of them
feel addressable.
... hopefully by the end of this month we will be ready.
... other thing is, some may be able to mark them as 7 day
close.
burn: I will go through and check them all
oliver: we still don't have JWT test cases. uPort will also
provide an implementation
... question about timeline for CR and features at risk.
manu: in general, don't worry. We will wait.
... but september is the end point
... things need to happen asap
burn: the main thing. PR is the last thing. Tony has said he
will raise objections.
... I will not be surprised if he raises objections that
require discussion, and that takes time.
... need to aim for PR at the end of the month. try to get
implementations in.
... as far as comment period. CR has expired. That is comments
from outside. the WG still addresses internal issues.
... comments from you that are implementation related will be
addressed.
manu: issue processing
<manu> [19]https://github.com/w3c/vc-data-model/issues/621
[19] https://github.com/w3c/vc-data-model/issues/621
manu: issue 621
... Oliver,I think you have a good handle on this. can you
summarize where we are?
oliver: the conclusion is we should provide language that
describes which attributes could have multiple types, or which
could change from objects to arrays.
... my team would like an exhaustive list.
<Justin_R> +1 to the request
manu: are you saying, you would like a list of every attribute
in the spec, or for everythin?
oliver: in the spec.
manu: I think we state in each attribute if it can be a single
value or an array.
... there are some examples of singletons.
... I think that information is implicit in the spec. We could
call it out in the implementation guide. or in the spec.
oliver: I would like something in the spec. I think we can have
non-normative statements around that.
Justin_R: It is imperative that the data elements specify their
arity. We need that in the data model.
... if it was always the intent that either type has always
been allowed for certain properties, that should be clarified.
<dmitriz> +1
+1
<ken> +1
<dlongley> +1 i think it's just clarification text
manu: we'll add spec text
... where should this be?
dmitriz: I think it is suffienct to say, everything may be
multiple, except these few singletons
manu: any objections?
Justin_R: I think since this was always the intent, we should
add clarifying normative language.
<manu>
[20]https://github.com/w3c/vc-data-model/issues/621#issuecommen
t-500877312
[20] https://github.com/w3c/vc-data-model/issues/621#issuecomment-500877312
manu: added that to the issue.
<manu> [21]https://github.com/w3c/vc-data-model/issues/642
[21] https://github.com/w3c/vc-data-model/issues/642
manu: next is 642, protocol buffer support
... why didn't you do protocol buffers? The @ character isn't
supported in protobufs
... from and to different serializations can be done.
... suggestion is to change nothing.
... we can change the text to mention protocol buffers.
<Zakim> Justin_R, you wanted to discuss serialization
manu: commenter hasn't responded. I think the spec is clear
already. If someone wants to add it, then add protocol buffer
support and mention mappings will need to be made.
Justin_R: serialization isn't really handled in the spec. this
same approach should apply to protocol buffers.
... to use any serialization, you need another spec to say how
to do that in either direction.
... this spec is the wrong place, but we need a family of specs
that very clearly state how to do that.
manu: are you saying, let's add language that points out that
need for more specs?
Justin_R: not suggesting we add that, it is already there.
manu: you're saying no change to the spec
<manu> [22]https://w3c.github.io/vc-data-model/#syntaxes
[22] https://w3c.github.io/vc-data-model/#syntaxes
Justin_R: I'm saying our response to the issue needs to be "any
necessary transforms to support protocol buffers requires a
different spec."
<Justin_R> Current text:
<Justin_R> A conforming document is any concrete expression of
the data model that complies with the normative statements in
this specification. Specifically, all relevant normative
statements in Sections § 4. Basic Concepts, § 5. Advanced
Concepts, and § 6. Syntaxes of this document MUST be enforced.
A serialization format for the conforming document MUST be
deterministic, bi-directional, and lossless as described in §
6. Syntaxes. The conforming document MAY [CUT]
<Zakim> burn, you wanted to say we have not defined how
extension to new syntaxes should occur
burn: Justin is right. we didn't say how extensions should
occur. We have provided examples.
... syntaxes have been described, but not serializations
... perhaps distracting now. Response to issue should be: our
expectation is that a new syntax should be written that
contains the serialization rules.
<manu> PROPOSAL: The Working Group has discussed issue 642 and
decided to make no changes to the specification. A response to
the issue submitter should instruct them to create a separate
serialization specification that maps the data model to and
from the serialization that they desire.
manu: any objections?
<Justin_R> wfm
RESOLUTION: The Working Group has discussed issue 642 and
decided to make no changes to the specification. A response to
the issue submitter should instruct them to create a separate
serialization specification that maps the data model to and
from the serialization that they desire.
burn: I think that's fine, but may lead to the question: what
do I do with the resulting spec?
... no objections
<manu> [23]https://github.com/w3c/vc-data-model/issues/653
[23] https://github.com/w3c/vc-data-model/issues/653
manu: next up 653. We just did a resolution for that with PR
658
... don't need to discuss 653
<manu> [24]https://github.com/w3c/vc-data-model/issues/654
[24] https://github.com/w3c/vc-data-model/issues/654
manu: 654, Ken you raised the issue and it was fixed with a
merged PR.
ken: please close it.
<manu> PROPOSAL: Issue #654 is addressed via PR #655. The PR
has been merged, close the issue after a 7 day wait period.
manu: any objections?
burn: I don't think we need a 7 day close
It is an internal issue
<manu> PROPOSAL: Issue #654 is addressed via PR #655. The PR
has been merged, close the issue immediately (no 7 day close).
manu: any objections?
RESOLUTION: Issue #654 is addressed via PR #655. The PR has
been merged, close the issue immediately (no 7 day close).
burn: no objections
<manu> [25]https://github.com/w3c/vc-data-model/issues/659
[25] https://github.com/w3c/vc-data-model/issues/659
<manu> brent: He had some questions about credential subject,
some other questions, I responded. I didn't say I don't think
we need to make changes, but we may want to do that.
burn: 659, support ticket as issue
<manu> PROPOSAL: Issue #659 has not resulted in any suggested
changes to the specification, the issue should be closed after
a 7 day wait period. Notify the issue submitter that we're
happy to continue the discussion with them in the issue or the
mailing list after the issue has been closed.
manu: working on re-wording the proposal
<manu> PROPOSAL: Issue #659 has not and does not appear likely
to result in any suggested changes, the issue should be closed
after a 7 day wait period. Notify the issue submitter that
questions should be directed to the mailing list for further
discussion.
burn: my suggestion, with the last sentence. we recommend to
move the discussion to the mailing list. and then do that.
<manu> PROPOSAL: Issue #659 has not and does not appear likely
to result in any suggested changes, the issue should be closed
after a 7 day wait period. Notify the issue submitter that we
are moving the discussion to the public-vc@w3.org mailing list.
burn: copy something from the issue into an email.
manu: any objections?
burn: none
RESOLUTION: Issue #659 has not and does not appear likely to
result in any suggested changes, the issue should be closed
after a 7 day wait period. Notify the issue submitter that we
are moving the discussion to the public-vc@w3.org mailing list.
<manu> [26]https://github.com/w3c/vc-data-model/issues/662
[26] https://github.com/w3c/vc-data-model/issues/662
manu: 662
... same kind of issue
<manu> PROPOSAL: Issue #662 has not and does not appear likely
to result in any suggested changes to specification text, the
issue should be closed after a 7 day wait period. Notify the
issue submitter that we are moving the discussion to the
public-vc@w3.org mailing list.
burn: no objections
RESOLUTION: Issue #662 has not and does not appear likely to
result in any suggested changes to specification text, the
issue should be closed after a 7 day wait period. Notify the
issue submitter that we are moving the discussion to the
public-vc@w3.org mailing list.
manu: and that is all the issues
... maybe a PR or two outstanding.
... it would really help it a full reading of the spec could be
done. put in PRs for editorial fixes.
... you may catch something weird with a full read-through
burn: let's move to test suite.
... actually, I would like to ask Justin if he could take over
as scribe
Justin_R: can't today
ken: I can do it
burn: but will you be talking?
<bigbluehat> scribenick: bigbluehat
<brent> ... thanks Benjamin
kaz: we're trying to identify some callers
Test Suite Issues and Discussion
burn: they are...but not in WebEx...
<burn> [27]https://github.com/w3c/vc-test-suite/issues
[27] https://github.com/w3c/vc-test-suite/issues
burn: did you update them kaz?
kaz: yes.
burn: thanks. anyway, test suite
... dmitriz, could you take us through outstanding issues on
the test suite?
dmitriz: we'll go through the PRs first in reverse
chronological order
<gannan> can we get a link?
<burn> [28]https://github.com/w3c/vc-test-suite/pulls
[28] https://github.com/w3c/vc-test-suite/pulls
<dmitriz> [29]https://github.com/w3c/vc-test-suite/pull/36
[29] https://github.com/w3c/vc-test-suite/pull/36
<dmitriz> (propose we merge)
<dmitriz> [30]https://github.com/w3c/vc-test-suite/pull/42 and
[31]https://github.com/w3c/vc-test-suite/pull/46
[30] https://github.com/w3c/vc-test-suite/pull/42
[31] https://github.com/w3c/vc-test-suite/pull/46
dmitriz: these are two exciting test results
... and now manu's cheering in IRC :)
burn: let's do these one at a time.
dmitriz: k. first, 42 the sovrin implementation
burn: can't see why there'd be objections
dmitriz: k. I'll click the button
... next is 46 for evernym
... and...no objections, so merging
... and while we're here, PR 36
burn: any objections to 36, the test suite sequence diagram?
... there haven't been since this was submitted
manu: so, we'll be able to see this once the merge is complete,
but I'm curious what features weren't implemented
<dmitriz> that was Ken
<dmitriz> and now Brent
brent: so, evernym's implementation is completely separate, so
we might be able to convince each other to do these
unimplemented features
... there were also JWT tests which weren't implemented...even
if oliver does
... these aren't objections to the feature, just a lack of time
burn: not sure where we are, oliver's on the queue
oliver: yeah, I'm curious. Do sovrin and evernym think its
possible to use JWT with these secret keys in general?
brent: at first glance, I don't think so.
... I believe we want to support receiving JWTs
... if they (IRMA) have a way to do it, I don't see why we
wouldn't
ken: we may have a ZKP style signature that we both read and
write
... and we'd heartily support bringing in JWT text-style
signatures that we can both read and write
... but we're not at that stage yet, but would love
contributors to help make that happen
burn: k. no other questions? back to you dmitriz
dmitriz: switching to the issue list, we have 2 new issues that
are unassigned
<dmitriz> [32]https://github.com/w3c/vc-test-suite/issues/45
[32] https://github.com/w3c/vc-test-suite/issues/45
dmitriz: one is issue 45 by brent
... I thought it was a companion to a test report
... but it looks like an error from brent
... what version of node are you using?
brent: version 8.10.0
dmitriz: and then we have issue 44
<dmitriz> [33]https://github.com/w3c/vc-test-suite/issues/44
[33] https://github.com/w3c/vc-test-suite/issues/44
dmitriz: issue about ZKP VC's
... question by yancy
... brent gives a response, so yancy do you have any further
questions?
yancy: I've not yet looked into the response
... my main question would be that looking to the ZKP test
suite
... that credential schema must exist or else its not valid
... but some of the earlier tests don't require schema if
they're not using ZKPs
<Zakim> manu, you wanted to note how
yancy: so I'm trying to figure out how the verifier can make
the distinction between the ZKP one and a non-ZKP one
manu: sorry, my audio crashed part way through, so apologies if
I've missed the question
... you essentially just look at the type
yancy: so in the proof section
... if the proof type is ZKP, so like example 22
... so that's supposed to mean it's a ZKP style proof?
manu: yes, exactly. My examples don't line up with yours
... so, yes, like that example, part of validating that proof
is checking for that schema
yancy: any other types like this?
<dlongley> the expectation is that your verifier understands
proof types -- if you don't, you reject the VC.
manu: clearly evernym and sovrin will need to jump in, but
that's the only one right now
... that might change, but that's how it is right now
... with LD signatures, you just check the type of the proof
and the schema to verfiy
... yes, you will need to specify a specification that explains
how to normalize the data
... it will look like RSA 2016 or those other specs
... if it's based on the LD signature stuff
... but if it's based on JWTs, it'll be based on something like
those
... the whole purpose was to allow these other cryptographic
methods to exist
... and those can bloom on a totally different timeline than
the VC spec does
jonathan_holt: so, I've been working on the JSON Schema
... so the credential attribute is on the body of the document
... are you requiring a credential schema on the proof object?
dmitriz: can I reply?
burn: yes
dmitriz: good question, this is an example on a previous call
... as far as I know, there isn't a way to do a conditional
check
... that'll need to be done in code
... if the type is ZKP, then this field is required
... so if you're using JSON Schema, then you'll have to set it
as optional
jonathan_holt: the newest version does, but I'm still learning
how to write those to support this
ken: so, like manu said, we should be ready for additional ZKP
styles as time goes forward
burn: so, would it be beyond the pale of what we're allowed to
do
... to add a clarifying statement, that it is recommended to
add a ZKP verifiable credential type?
... I understand that everyone's going to do their own thing
... but would it be inappropriate in our spec to have an
additional more narrow credential type to specificy that it's a
ZKP credential?
... dmitriz thoughts?
<Zakim> manu, you wanted to note that JSON Schema uses this
field differently from how ZKPs do...
dmitriz: well, I think it's more a question for you burn
because I'm not sure about CR breakage
manu: not sure if my opinion's well formed, but you can always
do that
... you can always add whatever new type to credentials , etc,
and that can trigger other code
... so there will be other specs that say, if you're encoding a
ZKP credential do it this way
... but I'd recommend against that, because there's unique
stuff in the proof that enables the ZKP verification of this
brent: so that schema point is the additional bit needed for
verification
... so if there's a way at the credential level, to let you
know you're going to need that schema in the proof
manu: I don't really think you need to do that for it to work
well or cleanly
... but maybe we should discuss this offline
<dlongley> there's no order to JSON keys... not sure what
"before you jump into the proof section" means
manu: I don't think you would need to fetch the credential
schema before you were in the process of doing the ZKP
validation
<yancy> +1 for not needing credentialSchema for a zkp
manu: I really feel like the type in the proof gives you what
you need to determine the algorithm
jonathan_holt: just to clarify, the JSON Schema really validate
the format, not the meaning
... I can validate that the attributes and values are there
... the meaning that this is now a ZKP credential, is more
embedded in the structure
manu: correct, semantics is beyond what JSON Schema was
designed to do
jonathan_holt: but conditional checks can be done, like if this
is a state, check for postal code
manu: correct
yancy: yeah, I'm wondering if it makes sense to somehow
... I guess I'm not convinced that a ZKP requires credential
schema
... I guess I was wondering if, for a Anoncred v1
... if it really requires credentialSchema
... that there might be other ZKP implementations that don't
require credentialSchema
ken: in order to do the proofs, the ordering of the data is
crtical
... there may be a way to do it without that, but right now
that's how its done
<manu> +1 to Ken for depending on proof.type declaration.
<dlongley> +1
ken: I'd prefer to use the type to pivot to determine if a
field is required or not
... I think that gives a better anchor
<dmitriz> +1
ken: rather than a sorting it out from properties
burn: lots of +1's but no one joining the queue
yancy: I think what I'm saying is in agreement with what was
just said
... the type in the proof section, would define whether
credentialSchema was required as well
<ken> I agree with Yancy
ken: and specifically anoncred requires it
<dmitriz> [34]https://github.com/w3c/vc-test-suite/issues/44
[34] https://github.com/w3c/vc-test-suite/issues/44
dmitriz: so, unless there's an objection, then I propose we
close the issue
yancy: so, I thought credentialSchema was required
... and it must be one or more credential schemas
... 5.4
manu: yeah, let me clarify that language
... we don't say you must have a credential schema
... but you can use credentialSchema to express data schemas,
but it must be of a certain format, etc
... we do this same pattern elsewhere, I think
... we also use an "if present, then..." style elsewhere
<dmitriz> maybe we can add the 'If present,' to section 5.4?
brent: if the intention of it is that further information is
needed to process the ZKP
... maybe the text just needs to be clarified to express that
manu: you mean in the ZKP section?
brent: yes. it says it, but it doesn't really say why
yancy: yeah, I was going to say that while you may not be
required to supply it
... if you're doing ZKP style tests, then...
... I was mainly suggesting that we modify the test suite
... so only if it's a ZKP, then it's anoncred-v1 type
brent: I don't think that matches the data model specification
dmitriz: I think this will get naturally solved
... if we get another ZKP implementation
... and if they pass the schema
... I don't think it's worth preemptively modifying
burn: we need to wrap up on this
... so a few more minutes on this topic
... or zero minutes :)
yancy: I'll just wait until we have more implementation details
... I agree with dmitriz
ken: I think it's kind of news to sovrin and evernym that there
are others using ZKP proofs
... so it might take more thinking on our parts to suggest ways
of dealing with new styles of ZKP proofs
... so I think we're a little early in figuring this out
... and perhaps offline would be the best place to discuss this
further
manu: just to agree with dmitriz, the current implementations
work with it this way
... so yancy if you've got an alternative ZKP mechanism, you
may want to specify it through a spec first
... so we can review it
... and I imagine your set of tests would be a different set of
optional tests than the sovrin one
... every mechanism that I know of needs that schema
... but if one exists, then it would need a totally different
set of rules, etc, for that particular type of ZKP
yancy: yep. that's fine
... I'll look into coordinating a spec for that
... I have more specifics to talk about, but it seems strange
to me that there's really only one implementation that requires
this
... so I think it'd be great if there were more implementations
beyond sovrin and evernym
burn: I want to be sure the resolution dmitriz wrote earlier,
hasn't changed
dmitriz: from everything I've heard, nothing changes for the
test suite
<manu> +1 to that
burn: alright, any last comments for today?
manu: just to request that people do a top-to-bottom review of
the spec
... and send PRs in for changes
... that would be super helpful at this point
dmitriz: I'm going to close issue 44
... if there are other questions, we can reopen
manu: burn do we want to set a target?
... there's no target, but I think we really should set one
... especially if we expect objections going to PR
... it looks like it needs to be in the next 2-3 weeks
burn: I agree with you
... it may seem premature
... but I was wanting to say by the end of the 3rd week of June
... but that's like 10-15 days away
... but we really do need a target like that
... if we wanted a goal to go to PR by the end of june, then we
really have to hit that
... why don't we say the 25th
... so, finishing CR, going to PR
... so, bring in those implementations, you have 2 weeks
ken: do we need to rerun our reports?
manu: yeah, you have to rerun
... or rather it would be a Good Thing if we all rerun them
... dmitriz would probably mention on a call, or running the
tests once a week
ken: k, if there are now changes, do I still need to rerun it
manu: yep, has to be latest and greatest
... and resubmit
burn: there are no police here other than us
... so it's not like there needs to be an automated script here
... just keep an eye on things
oliver: I'm OK with this, as long as implementers can submit
after this period
manu: well...yes, but when we go into PR, we need to draw a
hard line about what features got implementations, and which
didn't
... so if JWTs don't get enough implementations, those would
have to come out
... we want to hold on, so that can make it in
... but if you're saying that it'll be another couple months,
then we can't wait that long or the spec would be in danger
oliver: yeah. thanks. that's clear
... I think it's a requirement to stay in the spec
manu: have you talked to yancy and others about JWT
implementations?
burn: sadly, we're out of time. please take this one offline,
use email, etc.
... it is the WG that makes this decision.
... at that point, it's the end of the line and we'll ship it
... but it's the WG that makes that call
... Matt will be running the call next week
... I'll be on vacation
... do give Matt trouble next week
... bye all
Summary of Action Items
Summary of Resolutions
1. [35]The Working Group has confirmed that calling out the
phase of standardization that any particular specification
is in is not necessary as implementers can determine that
information from the heading information in each
specification as well as perusing the normative and
non-normative reference section.
2. [36]Merge PR 658 as it reflects the consensus of the
Working Group. Specifically, more organizations would
object to more stringent type requirements than what exists
in PR 658.
3. [37]The Working Group has discussed issue 642 and decided
to make no changes to the specification. A response to the
issue submitter should instruct them to create a separate
serialization specification that maps the data model to and
from the serialization that they desire.
4. [38]Issue #654 is addressed via PR #655. The PR has been
merged, close the issue immediately (no 7 day close).
5. [39]Issue #659 has not and does not appear likely to result
in any suggested changes, the issue should be closed after
a 7 day wait period. Notify the issue submitter that we are
moving the discussion to the public-vc@w3.org mailing list.
6. [40]Issue #662 has not and does not appear likely to result
in any suggested changes to specification text, the issue
should be closed after a 7 day wait period. Notify the
issue submitter that we are moving the discussion to the
public-vc@w3.org mailing list.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [41]scribe.perl version 1.154 ([42]CVS log)
$Date: 2019/06/17 11:15:33 $
[41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[42] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 17 June 2019 11:20:28 UTC