- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 8 Apr 2019 00:43:44 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/04/02-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Ganesh and Dave!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
02 Apr 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0030.html
Attendees
Present
Dan_Burnett, Dave_Longley, Ganesh_Annan, Justin_Richer,
Manu_Sporny, Tzviya_Siegman, Brent_Zundel, Amy_Guy,
Andrei_Sambra, Matt_Stone, Oliver_Terbu, Ken_Ebert,
Dmitri_Zagidulin, Kaz_Ashimura, Ted_Thibodeau,
Jonathan_Holt, Allen_Brown, Benjamin_Young, Joe_Andrieu,
Brian_Ulicny, Kaliya_Young, Ned_Smith, Yancy_Ribbens
Regrets
David_Chadwick
Chair
Dan_Burnett, Matt_Stone
Scribe
dlongley, gannan
Contents
* [3]Topics
1. [4]Agenda review, Introductions, Re-introductions
2. [5]PR review
3. [6]Any other business?
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<dlongley> scribenick: dlongley
Agenda review, Introductions, Re-introductions
burn: We're going to start with reviewing PRs. Then we'll look
at issues, we won't start with assigning names to issues and
I'll give background on that in a moment. Anyone joining for
the first time today?
... Manu would you like to reintroduce yourself?
manu: Hi, I'm Manu Sporny. I work at Digital Bazaar. We've been
involved in the VC stuff for quite a while, a number of our
products utilize the tech. We work with large gov't, banking,
finance, etc customers. Look forward to the spec reaching REC
this year.
burn: The chairs and editors have has some more conversations
and we'd like to cover a few important points.
... The spec was published as CR last Thursday, yay!
<manu> yaaay! to CR being published :))))
burn: In addition, the group has been extended to the end of
September, congratulations to everyone.
<dmitriz> yayyyy!!!
<manu> yaaay! for administrative Charter extension!!!!
burn: This is what we were hoping for and it's confirmed now.
... At this stage, our groups work and the status of our spec
is a little at risk. I will put this bluntly. It is at risk
from two kinds of people. Those that wish the group to fail and
those that believe that what they want is more important than
having the group succeed.
... There are 4 ways this can manifest. 1. Trolling of the
issues list. Intentionally or unintentionally splitting the
group over some issue that's not worth destroying the spec
over.
... 2. Trolling of our issues list by proposing unnecessary
normative changes that would force us to have another CR.
... 3. Responding slowly to discussions or at the very last
moment. Malicious responders will do this to make the group go
past its charter time. It can also happen if the group loses
focus.
... 4. Someone arguing that someone has not addressed the issue
after the group has considered it and made a decision. That can
happen sometimes but people who wish the group ill will tend to
do this. We have some suspicion that there are people that do
feel that way about the group.
... I'm going to go over some more about this. At this point a
single normative change will require a new CR. To issue a new
one we would need a successful publication vote near the end of
May. We'd need wide review by the end of April.
... Here are the guidelines and rules that we plan to follow.
Our goal is to not make any normative changes unless absolutely
necessary. If we MUST then we need to make them right away. If
there's something that really must happen, don't wait.
... For every issue, we will either request or propose
non-normative spec changes if possible.
... The reason for this is to provide that we have indeed
considered the issue. We will be going from a 14-day default
close to a 7-day default close. I'm not happy about this but I
think it's the way we'll have to go.
... It doesn't mean that if there is strong objection to the
close and that person is on vacation we can't make exceptions.
... But in order to keep the work moving it's dangerous for 14
days ... if you don't respond to close it because people might
wait 14 days and then give a comment and then do it again and
then we're over time.
... We will open a closed issue but only if new information is
brought. This is appropriate at this stage, it is what CR
means.
... Ok, thank you.
... Looking for a new scribe...
<scribe> scribenick: gannan
PR review
<manu> [9]https://github.com/w3c/vc-data-model/issues/492
[9] https://github.com/w3c/vc-data-model/issues/492
manu: We're going to reference the issues first and then talk
about the PRs
<burn>
[10]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+-label%3Adefer
[10] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:defer
<manu> [11]https://github.com/w3c/vc-data-model/pull/510
[11] https://github.com/w3c/vc-data-model/pull/510
manu: Tony Nadalin raised a concern that issues about private
browsing mode in different browsers and he wanted to point out
that each browser may or may not have private browsing mode
... Brent addressed the issue in his PR with a non-normative
change
... Any objections? If not I will make a proposal.
<manu> PROPOSED: Merge non-normative PR #510 in order to
clarify private-browsing mode concerns raised in issue #492.
<dlongley> +1
burn: Focused on closing issues and minimizing discussion. We
want to be clear with our resolutions so that they're entered
into the minutes.
<brent> +1
<ken> +1
<TallTed> +1
<deiu> +1
<tzviya> +1
<stonematt> +1
<burn> +1
<oliver_terbu> +1
<manu> +1
manu: Ensure that only one representative from the company is
adding a +1.
TallTed: In a working group this is not the case, it is one
person, one vote.
<stonematt> +1 to call for objections in following resolutions
burn: I would rather not do a vote and just call for
objections.
RESOLUTION: Merge non-normative PR #510 in order to clarify
private-browsing mode concerns raised in issue #492.
<manu> [12]https://github.com/w3c/vc-data-model/issues/493
[12] https://github.com/w3c/vc-data-model/issues/493
<manu> [13]https://github.com/w3c/vc-data-model/pull/499
[13] https://github.com/w3c/vc-data-model/pull/499
manu: Next PR has to do with security considerations section,
issue 493. Tony is asserting that there are lowercase musts in
a non-normative sections. Chaals created a PR with
non-normative changes to address Tony's concerns. It changes
text from "must" to "needs to"
<manu> PROPOSED: Merge non-normative PR #499 in order to
clarify that existing 'must' was not a normative statement,
which was raised in issue #493. Close issue #493 after the
merge.
manu: any objections to that proposal?
RESOLUTION: Merge non-normative PR #499 in order to clarify
that existing 'must' was not a normative statement, which was
raised in issue #493. Close issue #493 after the merge.
<manu> [14]https://github.com/w3c/vc-data-model/issues/495
[14] https://github.com/w3c/vc-data-model/issues/495
manu: PR for token binding, issue 495
<manu> [15]https://github.com/w3c/vc-data-model/pull/497
[15] https://github.com/w3c/vc-data-model/pull/497
manu: ... Tony is requesting we link to RFC ???, we have a PR
that updates a link to the specification
<manu> PROPOSED: Merge non-normative PR #497 in order to update
to an informative reference to RFC8471 raised in issue #495.
Close issue #495 once the PR is merged.
manu: any objections?
RESOLUTION: Merge non-normative PR #497 in order to update to
an informative reference to RFC8471 raised in issue #495. Close
issue #495 once the PR is merged.
<manu> [16]https://github.com/w3c/vc-data-model/issues/482
[16] https://github.com/w3c/vc-data-model/issues/482
manu: Next item, issue 482. Tony asserts that the introduction
is misleading because it talks about digital signatures...
... ...our specification doesn't standardize on proof formats
<manu> PROPOSED: Add more clarifying text to the specification
noting that while the specification does not standardize on
signature format, the WG is aware of at least three mechanisms
(JWTs, LD-Proofs, and ZKPs) that are capable of protecting the
contents of the data model at the time of publication that are
being used in deployments of the technology and expects those
mechanisms to mature independently as well as new mechanisms to
become standardized.
manu: ...we would make a non normative clarification to the
spec
... ...the spec already states that we are not choosing one
signature mechanism, we are proof agnostic
... any objections?
Justin_R: no objections, I think it is the right way to go. I
want to make sure that the existing text does veer towards LD
as the base model...
... ...and everything else is an expression of the LD model
<jonathan_holt> 1+
manu: can you suggest in the issue or in the PR some concrete
non-normative spec changes?
Justin_R: sure, could you tag me as a reviewer so I can look at
it. To prevent stepping on each others toes.
burn: Let's make sure we can do that.
Justin_R: Or a comment.
manu: Taking note of that.
Justin_R: Thank you.
manu: any objections?
RESOLUTION: Add more clarifying text to the specification
noting that while the specification does not standardize on
signature format, the WG is aware of at least three mechanisms
(JWTs, LD-Proofs, and ZKPs) that are capable of protecting the
contents of the data model at the time of publication that are
being used in deployments of the technology and expects those
mechanisms to mature independently as well as new mechanisms to
become standardized.
<manu> [17]https://github.com/w3c/vc-data-model/issues/483
[17] https://github.com/w3c/vc-data-model/issues/483
manu: next, section 4.1 @context... issue 483
... ...tony has asserted that there is no reason to have a
@context, it should be removed or made optional
... ...there has been a lot of discussion around interop
between json only and json-ld processors
... ...we've been discussing this for a long time and the
points that Tony raised has been discussed by the working group
... ...the working group made a vote to make @context mandatory
in our f2f meeting with broad agreement
... ...you do not need to process @context when using a JSON
only processor
<manu> PROPOSED: The VCWG had considered all points raised by
issue #483 throughout the lifetime of the WG's operation, no
new information was provided by issue #483 to convince the WG
to change @context being mandatory (which has broad support in
the WG with no objections), and thus the issue should be closed
with no changes to the specification.
manu: any objections?
jonathan_holt: It goes into the mime-type discussion we had in
Barcelona, we should require @context
manu: To be clear you are saying that this is part of the
conversation, you are not rejecting the proposal
... that is a formal objection, we are requiring @context
<dlongley> the `@context` is on the `vc` .. not on the JWT. ...
is this a clarification we need?
jonathan_holt: we should be specific on when @context is
required
manu: we need some spec text
jonathan_holt: I'll bubble up my issue
<Zakim> brent, you wanted to say text clarification that
explicitly points out that if the data model is encoded as a
JWT, no processing of the @context is expected may be helpful
burn: It might be more efficient to have a conversation
brent: I think it we added some text that clarifies if the data
model is processed as a JWT then no processing of @context is
needed
... @context needs to be present but need not be processed by
their processor
manu: we can't proceed... need to have a conversation with
jonathan_holt... brent go ahead and write a PR with this issue
and potentially others
TallTed: what I'm seeing in this issue thread, is not an issue
about processing the @context content. It's about someone
working exclusively with JWT's and do not want to have @context
in their credential and they have no care for JSON-LD
manu: It's necessary for the data encapsulated in the JWTs, if
it's not in the VC then it's semantically ambiguous
TallTed: That needs to be addressed
manu: That is addressed in issue 491
<dlongley> +1 it's not about JWT, it's about the payload IN the
JWT.
TallTed: We need to address what others that don't understand,
@context should be in the payload in the JWT
manu: We'll refer to this in the issue
Justin_R: It sounds like that fundamentally a VC is JSON-LD doc
with many types of expression
... ... if that's the case then we need to be explicit, if not
then these issues do have merit
manu: It's not just a JSON-LD document, it's a hybrid. We have
something that could just use JSON processing or JSON-LD
processing
<manu> [18]https://github.com/w3c/vc-data-model/issues/494
[18] https://github.com/w3c/vc-data-model/issues/494
manu: this needs more discussion
... In the next issue, has to do with content integrity
... Tony says there is no need to have content integrity in
JWTs
... This is talking about links in documents, we warn that
outgoing links need content integrity, JWTs do not solve that
problem
<manu> PROPOSED: The content-integrity section of the
specification describes how outgoing links from a document may
be protected. Issue #494 asserts that JWTs provide
content-integrity protection for outgoing links, which is
false.The VCWG is also supportive of the use of @context as a
core part of the data model. Issue #494 should be closed with
no changes to the specification.
manu: Basically, no change to the spec. It's a non-normative
section, we are not saying you need to have content integrity
for outgoing links but recommend a few mechanisms to achieve
this
... any objections?
RESOLUTION: The content-integrity section of the specification
describes how outgoing links from a document may be protected.
Issue #494 asserts that JWTs provide content-integrity
protection for outgoing links, which is false.The VCWG is also
supportive of the use of @context as a core part of the data
model. Issue #494 should be closed with no changes to the
specification.
<manu> [19]https://github.com/w3c/vc-data-model/issues/498
[19] https://github.com/w3c/vc-data-model/issues/498
manu: next is issue 498, Tony says that there are no
interoperable parts of the spec that makes it verifiable
<TallTed> TallTed: "JWTs provide content-integrity protection
for outgoing links" = true. "JWTs provide content-integrity
protection for content of outgoing links" = false.
manu: ...remove verifiable from the spec and make JWTs the
normative way of expressing credentials
... ...the issue is about the title of the specification and
removing the word verifiable
<manu> PROPOSED: The specification clearly defines the meaning
of "verifiable credential" and the VCWG has spent a
considerable amount of time discussing and running surveys on
the proper name for the specification. The VCWG believes the
name of the specification is appropriate. Issue #498 should be
closed with no change to the title of the specification.
manu: ...the group has had a long discussion and agreed that it
should be the "Verifiable Credentials" data model
... any objections?
RESOLUTION: The specification clearly defines the meaning of
"verifiable credential" and the VCWG has spent a considerable
amount of time discussing and running surveys on the proper
name for the specification. The VCWG believes the name of the
specification is appropriate. Issue #498 should be closed with
no change to the title of the specification.
<dlongley> [20]https://github.com/w3c/vc-data-model/issues/502
[20] https://github.com/w3c/vc-data-model/issues/502
manu: next is a charter comment. Tony is mentioning that the
web-authn should have been a liason in the charter. He wants to
have a charter update. We just got a charter extension so we
can't change the charter. Tony is the co-chair of the group and
has made a full review of the specification already. The Web
Authn group has the ability to do any additional reviews
burn: we are not changing the charter
... we do not need a formal liason relationship for comments to
be made on the specification
<manu> PROPOSED: The VCWG notes that the charter cannot be
changed at present and thus new Liaison relationships cannot be
added. The VCWG also notes and is thankful of the review of the
specification that has been performed by Tony Nadalin, who is a
co-chair of the WebAuthn WG, and welcomes comments from all
interested Working Groups. Issue #513 should be closed with no
change to the specification.
manu: this is the new re-worked proposal?
burn: any objections?
RESOLUTION: The VCWG notes that the charter cannot be changed
at present and thus new Liaison relationships cannot be added.
The VCWG also notes and is thankful of the review of the
specification that has been performed by Tony Nadalin, who is a
co-chair of the WebAuthn WG, and welcomes comments from all
interested Working Groups. Issue #513 should be closed with no
change to the specification.
<manu> [21]https://github.com/w3c/vc-data-model/issues/513
[21] https://github.com/w3c/vc-data-model/issues/513
kaz: The first two proposals should be removed from the minutes
later because they're overridden by the third proposal
manu: correct
(Originally there were three proposals made during the call,
but the first two proposals have been removed and only the
final proposal confirmed is recorded above)
manu: Tony says that JWKs should be listed as a normative
reference, brent and oliver had a back and forth in the
comments. It seems that JWKs are not listed
<manu> PROPOSED: Add non-normative text to the specification
that makes an informative reference to the JWK specification
and notes that key discovery can be performed in a variety of
ways including the use of JWK and DID-based key discovery.
manu: ...the suggestion is to make a non-normative spec change
that points to JWK as a way to describe keys but not the only
way
... any objections to that proposal?
<Justin_R> +1 informative references to examples are good
<Justin_R> (I had raised this previously)
RESOLUTION: Add non-normative text to the specification that
makes an informative reference to the JWK specification and
notes that key discovery can be performed in a variety of ways
including the use of JWK and DID-based key discovery.
<Justin_R> np
<manu> [22]https://github.com/w3c/vc-data-model/issues/490
[22] https://github.com/w3c/vc-data-model/issues/490
Justin_R: going to tag you in the resolution, since you had
some concerns
manu: issue 490, this is about the Trust Model. Section 5.2
which is non-normative. We talk about what the Trust Model
should be, it's not the only one
... tony suggests that this should be put at-risk, I've seen no
spec that has put non-normative text as at-risk
... nothing in this section has implementation burden so
there's no reason to mark it at risk
<manu> PROPOSED: Section 5.2: Trust Model is a non-normative
section on the specification. Issue #490 asserts that it should
be marked at risk. Non-normative sections contain no normative
statements and thus are not at risk during or after the
Candidate Recommendation phase. Issue #490 should be closed
with no changes to the specification.
manu: it's a no change to the specification
<TallTed> +1 non-normative, so no implementation expected, so
can't be at-risk
burn: at risk as I understood it during my 20years, at risk
means at risk from removal from the specification due to
insufficient implementation
kaz: just want to confirm that the feature we're discussing
wouldn't impact implementations
(burn agrees that is a good point, and doesn't think it would
impact implementations)
manu: any objections?
RESOLUTION: Section 5.2: Trust Model is a non-normative section
on the specification. Issue #490 asserts that it should be
marked at risk. Non-normative sections contain no normative
statements and thus are not at risk during or after the
Candidate Recommendation phase. Issue #490 should be closed
with no changes to the specification.
manu: do the chairs want to wrap up or process one more issue?
burn: it'd be good to wrap up
Any other business?
Kaliya mentions she and Heather have published a book which has
a chapter on Verifiable Credentials
burn: any questions or comments before we end the call?
yancy: just wanted to say I raised a few issues on the test
suite, would like some responses
burn: we need to discuss this, test could change because they
were implemented incorrectly or there was an update to
normative references
dmitriz: can we work on it next call?
burn: would prefer to continue it offline
... to short notice, but the chairs can talk about a way too
have more working calls between our meetings
... thank you everyone, bye
Summary of Action Items
Summary of Resolutions
1. [23]Merge non-normative PR #510 in order to clarify
private-browsing mode concerns raised in issue #492.
2. [24]Merge non-normative PR #499 in order to clarify that
existing 'must' was not a normative statement, which was
raised in issue #493. Close issue #493 after the merge.
3. [25]Merge non-normative PR #497 in order to update to an
informative reference to RFC8471 raised in issue #495.
Close issue #495 once the PR is merged.
4. [26]Add more clarifying text to the specification noting
that while the specification does not standardize on
signature format, the WG is aware of at least three
mechanisms (JWTs, LD-Proofs, and ZKPs) that are capable of
protecting the contents of the data model at the time of
publication that are being used in deployments of the
technology and expects those mechanisms to mature
independently as well as new mechanisms to become
standardized.
5. [27]The content-integrity section of the specification
describes how outgoing links from a document may be
protected. Issue #494 asserts that JWTs provide
content-integrity protection for outgoing links, which is
false.The VCWG is also supportive of the use of @context as
a core part of the data model. Issue #494 should be closed
with no changes to the specification.
6. [28]The specification clearly defines the meaning of
"verifiable credential" and the VCWG has spent a
considerable amount of time discussing and running surveys
on the proper name for the specification. The VCWG believes
the name of the specification is appropriate. Issue #498
should be closed with no change to the title of the
specification.
7. [29]The VCWG notes that the charter cannot be changed at
present and thus new Liaison relationships cannot be added.
The VCWG also notes and is thankful of the review of the
specification that has been performed by Tony Nadalin, who
is a co-chair of the WebAuthn WG, and welcomes comments
from all interested Working Groups. Issue #513 should be
closed with no change to the specification.
8. [30]Add non-normative text to the specification that makes
an informative reference to the JWK specification and notes
that key discovery can be performed in a variety of ways
including the use of JWK and DID-based key discovery.
9. [31]Section 5.2: Trust Model is a non-normative section on
the specification. Issue #490 asserts that it should be
marked at risk. Non-normative sections contain no normative
statements and thus are not at risk during or after the
Candidate Recommendation phase. Issue #490 should be closed
with no changes to the specification.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [32]scribe.perl version 1.154 ([33]CVS log)
$Date: 2019/04/07 15:41:39 $
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[33] http://dev.w3.org/cvsweb/2002/scribe/
Received on Sunday, 7 April 2019 15:44:52 UTC