- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 17 Apr 2019 02:25:23 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/04/16-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Ted and Dave!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
16 Apr 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0013.html
Attendees
Present
Amy_Guy, Brent_Zundel, Dan_Burnett, Dave_Longley,
David_Chadwick, Ganesh_Annan, Jonathan_Holt,
Justin_Richer, Kaliya_Young, Kaz_Ashimura, Ken_Ebert,
Manu_Sporny, Matt_Stone, Nick_Carroll, Sercan_Kum,
Ted_Thibodeau, Yancy_Ribbens, Oliver_Terbu,
Nathan_George
Regrets
Andrei_Samba
Chair
Dan_Burnett, Matt_Stone
Scribe
TallTed
Contents
* [3]Topics
1. [4]plan/agenda
2. [5]PR announcements
3. [6]Issue lightning round: close the issues we can
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<burn> scribenick: TallTed
plan/agenda
burn: we'll start with PR announcements (mostly not
decision-making), and move into an "issue lightning round" to
quickly close what we can
... not to run over disagreements -- discussion can be
scheduled for another call
... proposing increasing call duration to 2 hours
burn: with a shift to start 1 hour earlier
<manu> +1 to starting call 1 hour earlier.
<stonematt> +1 to starting earlier
<manu> also, fwiw -- +1 to running call for extra hour today.
<jonathan_holt> +1 but starting next week
<DavidC> +1
<dlongley> +1 fine with doing it this week
<jonathan_holt> I don't want to miss the CCG meeting
<ken> -1 for today
<Zakim> manu, you wanted to ask about overlap?
<ken> +1 starting next week
<manu> current CCG agenda - TL;DR: EOY Survey Results, cont'd
and Code of Conduct and Conflict Management (if time permits)
PR announcements
<manu> [9]https://github.com/w3c/vc-data-model/pulls
[9] https://github.com/w3c/vc-data-model/pulls
manu: we have an increasing backlog, including 5 large PRs from
grant noble
... these will cause merge conflicts with every other PR ...
which will need to be fixed ASAP
<manu> [10]https://github.com/w3c/vc-data-model/pull/539
[10] https://github.com/w3c/vc-data-model/pull/539
<manu> [11]https://github.com/w3c/vc-data-model/pull/550
[11] https://github.com/w3c/vc-data-model/pull/550
<manu> [12]https://github.com/w3c/vc-data-model/pull/542
[12] https://github.com/w3c/vc-data-model/pull/542
manu: generally in good shape -- ready to merge or discussion
is ongoing
<manu> [13]https://github.com/w3c/vc-data-model/pull/542/files
[13] https://github.com/w3c/vc-data-model/pull/542/files
manu: asserting that PR#542 is a bug-fix to normative text
[ no objections to assertion ]
manu: any other concerns on PRs? need extra call time for any
PR?
[ silence ]
Issue lightning round: close the issues we can
<Justin_R> @manu -- I looked just now and there was one line
that I'd missed from your comments (it was right next to
another line that was fixed and I missed the repeated term).
<Justin_R> Everything else is in there though so please review
<Justin_R> This is for #539
<burn>
[14]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+-label%3Adefer
[14] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:defer
manu: these are all proposals; primarily looking for objections
<manu> [15]https://github.com/w3c/vc-data-model/pull/542/files
[15] https://github.com/w3c/vc-data-model/pull/542/files
<manu> [16]https://github.com/w3c/vc-data-model/issues/520
[16] https://github.com/w3c/vc-data-model/issues/520
manu: issue suggests using a JWK (seems really to mean JWT) as
a VC
... WG has clarified that a JWT is not a VC, but a JWT can be
used to secure a VC
manu: language around context processing is being clarified
<manu> PROPOSED: A JWT is not a Verifiable Credential as the
data models differ. A JWT can be used to secure a Verifiable
Credential as described in Section 6.3.1. The language related
to @context processing for JWT-based processors should be
clarified to note that dereferencing @context values is not
required, which is a non-substantive clarification to the
existing text in the specification. The IANA registration for
the vc and vp JWT claims should be separated into an IANA
Considerations section. Issue #520 should be closed after the
PR is merged.
[ no objections ]
RESOLUTION: A JWT is not a Verifiable Credential as the data
models differ. A JWT can be used to secure a Verifiable
Credential as described in Section 6.3.1. The language related
to @context processing for JWT-based processors should be
clarified to note that dereferencing @context values is not
required, which is a non-substantive clarification to the
existing text in the specification. The IANA registration for
the vc and vp JWT claims should be separated into an IANA
Considerations section. Issue #520 should be closed after the
PR is merged.
<manu> [17]https://github.com/w3c/vc-data-model/issues/523
[17] https://github.com/w3c/vc-data-model/issues/523
<manu> PROPOSED: One of the goals of the Verifiable Credentials
Data Model specification is to define extensibility points in
the data model and achieve interoperability on the
extensibility points (not the extensions themselves). The
interoperability tests will focus on ensuring that the minimum
information exists in extensions to identify the extension
without needing to define each extension in detail for this
iteration of the Working Group. Defining extensions to the base
data model is outside of the scope of the WG's charter. All
features that the Working Group deems at risk were marked
before entering CR. No new at-risk features have been
identified after processing issue #523, which should be closed
with no changes to the specification.
[ no objections ]
RESOLUTION: One of the goals of the Verifiable Credentials Data
Model specification is to define extensibility points in the
data model and achieve interoperability on the extensibility
points (not the extensions themselves). The interoperability
tests will focus on ensuring that the minimum information
exists in extensions to identify the extension without needing
to define each extension in detail for this iteration of the
Working Group. Defining extensions to the base data model is
outside of the scope of the WG's charter. All features that the
Working Group deems at risk were marked before entering CR. No
new at-risk features have been identified after processing
issue #523, which should be closed with no changes to the
specification.
<manu> [18]https://github.com/w3c/vc-data-model/issues/524
[18] https://github.com/w3c/vc-data-model/issues/524
<manu> PROPOSED: The VCWG seeks to demonstrate interoperability
at the data model and extension points in the specification,
not the extensions themselves as the group is not chartered to
work on extensions. The VCWG has reviewed all conformance
statements, has implemented a test suite that tests all
required conformance statements in the specification, and
asserts that this approach is appropriate for a data model
specification. Section 5.3 should be marked as
<manu> non-normative as it does not contain any normative
statements. Section 5.3.1 should remain normative. These are
non-substantive changes and once they are made, issue #524
should be closed.
scribenick: dlongley
TallTed: Section 5.3 cannot be non-normative if Section 5.3.1
is normative. You can't have a non-normative section with
normative subsections.
burn: You can do it the other way around though.
manu: I defer to you, Ted. I thought you could have massive
non-normative sections and mark subsections as normative.
<rhiaro> Logically what Ted says makes sense to me
<brent> +1 to TallTed
TallTed: I don't believe so. Unless you have huge red flags at
the top that say there's some tiny section that is normative.
... But that doesn't really work out.
<dlongley> manu writes up a new proposal
<burn> Ted is right. Implementers read 'non-normative' at the
top and ignore the contents. The reverse is okay, labeling
normative at the top and having subsections be non-normative
<burn> The end result is the same either way, just better
understood
TallTed: To be clear, it is fine to put into each of the other
subsections that it is non-normative.
manu: But that's not the case we have here, it's the opposite.
TallTed: It's not ok to have 5.3 non-normative and 5.3.1 as
normative, but we can individually label subsections as
non-normative. 5.3 normative, 5.3.1 normative, 5.3.2
non-normative, 5.3.3 non-normative, etc -- it just needs to be
labeled individually.
<Justin_R> +1 to Tall_Ted's suggestion
burn: Let's take this offline. Ted is correct, but the end
result is the same as what you want. You can't have a normative
within a non-normative.
<manu> PROPOSED: The VCWG seeks to demonstrate interoperability
at the data model and extension points in the specification,
not the extensions themselves as the group is not chartered to
work on extensions. The VCWG has reviewed all conformance
statements, has implemented a test suite that tests all
required conformance statements in the specification, and
asserts that this approach is appropriate for a data model
specification. Section 5.3 should remain normative as it
contains a normative section 5.3.1. Section 5.3.1 should remain
normative. Other PRs are in process that clarify the findings
of this proposal and once they are made, issue #524 should be
closed.
manu: There are no sections 5.3.2+.
<kaz> [19]section 5.3
[19] https://w3c.github.io/vc-data-model/#extensibility
scribenick: TallTed
[ no objections ]
RESOLUTION: The VCWG seeks to demonstrate interoperability at
the data model and extension points in the specification, not
the extensions themselves as the group is not chartered to work
on extensions. The VCWG has reviewed all conformance
statements, has implemented a test suite that tests all
required conformance statements in the specification, and
asserts that this approach is appropriate for a data model
specification. Section 5.3 should remain normative as it
contains a normative section 5.3.1. Section 5.3.1 should remain
normative. Other PRs are in process that clarify the findings
of this proposal and once they are made, issue #524 should be
closed.
<manu> [20]https://github.com/w3c/vc-data-model/issues/525
[20] https://github.com/w3c/vc-data-model/issues/525
<manu> PROPOSED: Non-normatively elaborate on the JSON
Verifiable Credential processor rule that ensures that the
array of values associated with @context should be in the
expected order for the processor. Close issue #525 after the PR
has been merged.
<manu> PROPOSED: Editors will non-normatively elaborate on the
rules that ensure that the array of values associated with
@context should be in the expected order. Close issue #525
after the PR has been merged.
[ no objection ]
RESOLUTION: Editors will non-normatively elaborate on the rules
that ensure that the array of values associated with @context
should be in the expected order. Close issue #525 after the PR
has been merged.
<manu> [21]https://github.com/w3c/vc-data-model/issues/394
[21] https://github.com/w3c/vc-data-model/issues/394
<manu> PROPOSED: Multiple non-normative commits and PRs (#475,
#499) have been written, reviewed and applied for this issue.
The WG does not believe that any more mis-characterized
normative terminology appears in non-normative sections. Issue
#394 should be closed.
[ no objection ]
RESOLUTION: Multiple non-normative commits and PRs (#475, #499)
have been written, reviewed and applied for this issue. The WG
does not believe that any more mis-characterized normative
terminology appears in non-normative sections. Issue #394
should be closed.
<manu> [22]https://github.com/w3c/vc-data-model/issues/462
[22] https://github.com/w3c/vc-data-model/issues/462
<manu> PROPOSED: Issue #462 is addressed by PR #503, which
makes non-normative changes detailing type information stored
in a credential as requested by the reviewer. The PR has been
approved by multiple parties and has been merged. Issue #462
should be closed.
[ no objection ]
RESOLUTION: Issue #462 is addressed by PR #503, which makes
non-normative changes detailing type information stored in a
credential as requested by the reviewer. The PR has been
approved by multiple parties and has been merged. Issue #462
should be closed.
<manu> [23]https://github.com/w3c/vc-data-model/issues/463
[23] https://github.com/w3c/vc-data-model/issues/463
<manu> PROPOSED: Issue #463 is addressed by PR #504, which
makes non-normative changes to updated the definition of an
entity requested by the reviewer. The PR has been approved by
multiple parties and has been merged. Issue #463 should be
closed.
[ no objection ]
RESOLUTION: Issue #463 is addressed by PR #504, which makes
non-normative changes to updated the definition of an entity
requested by the reviewer. The PR has been approved by multiple
parties and has been merged. Issue #463 should be closed.
<manu> [24]https://github.com/w3c/vc-data-model/issues/464
[24] https://github.com/w3c/vc-data-model/issues/464
<manu> PROPOSED: Issue #464 is addressed by PR #512, which
makes non-normative changes related to the subject of the
credential as requested by the reviewer. The PR has been
approved by multiple parties and has been merged. Issue #464
should be closed.
[ no objection ]
RESOLUTION: Issue #464 is addressed by PR #512, which makes
non-normative changes related to the subject of the credential
as requested by the reviewer. The PR has been approved by
multiple parties and has been merged. Issue #464 should be
closed.
<manu> [25]https://github.com/w3c/vc-data-model/issues/466
[25] https://github.com/w3c/vc-data-model/issues/466
<manu> PROPOSED: Issue #466 is addressed by PR #477, which
makes minor non-normative changes by changing "might perform"
to "performs" for certain roles as requested by the reviewer.
The PR has been approved by multiple parties and has been
merged. Issue #466 should be closed.
[ no objection ]
RESOLUTION: Issue #466 is addressed by PR #477, which makes
minor non-normative changes by changing "might perform" to
"performs" for certain roles as requested by the reviewer. The
PR has been approved by multiple parties and has been merged.
Issue #466 should be closed.
<manu> [26]https://github.com/w3c/vc-data-model/issues/471
[26] https://github.com/w3c/vc-data-model/issues/471
<manu> PROPOSED: Issue #471 is addressed by PR #507, which
makes non-normative changes pointing out that trust is
bilateral between issuers and verifiers as requested by the
reviewer. The PR has been approved by multiple parties
(including the reviewer), and has been merged. Issue #471
should be closed.
[ no objection ]
RESOLUTION: Issue #471 is addressed by PR #507, which makes
non-normative changes pointing out that trust is bilateral
between issuers and verifiers as requested by the reviewer. The
PR has been approved by multiple parties (including the
reviewer), and has been merged. Issue #471 should be closed.
<inserted> (burn suggest we extend the VCWG call today by 15
mins at max to finish out the issue list)
<TallTed> +1 finish out the list
<stonematt> +1 to finish the list
<dlongley> +1 to finish the list
<brent> +1 to continuing the VCWG call
<manu> +1, let's go finish the list! :)
<SercanK> +1 finish the list
<manu> [27]https://github.com/w3c/vc-data-model/issues/472
[27] https://github.com/w3c/vc-data-model/issues/472
<manu> PROPOSED: Issue #472 is addressed by PR #476, which
makes non-normative changes noting that consent isn't implied
by signatures on presentations as requested by the reviewer.
The PR has been approved by multiple parties and has been
merged. Issue #472 should be closed.
[ no objection ]
RESOLUTION: Issue #472 is addressed by PR #476, which makes
non-normative changes noting that consent isn't implied by
signatures on presentations as requested by the reviewer. The
PR has been approved by multiple parties and has been merged.
Issue #472 should be closed.
<manu> [28]https://github.com/w3c/vc-data-model/issues/481
[28] https://github.com/w3c/vc-data-model/issues/481
<manu> PROPOSED: Issue #481 is addressed by PR #508 and PR
#509, which make multiple non-normative changes to the
definitions of roles in the ecosystem as requested by the
reviewer. The PR has been approved by multiple parties and have
been merged. Issue #481 should be closed.
[ no objection ]
RESOLUTION: Issue #481 is addressed by PR #508 and PR #509,
which make multiple non-normative changes to the definitions of
roles in the ecosystem as requested by the reviewer. The PR has
been approved by multiple parties and have been merged. Issue
#481 should be closed.
<manu> [29]https://github.com/w3c/vc-data-model/issues/485
[29] https://github.com/w3c/vc-data-model/issues/485
<manu> PROPOSED: Issue #485 is addressed by PR #519, which
makes non-normative changes noting that a JWK can also be used
in the place of an `issuer` property as requested by the
reviewer. The PR has been approved by multiple parties and has
been merged. Issue #485 should be closed.
[ no objection ]
RESOLUTION: Issue #485 is addressed by PR #519, which makes
non-normative changes noting that a JWK can also be used in the
place of an `issuer` property as requested by the reviewer. The
PR has been approved by multiple parties and has been merged.
Issue #485 should be closed.
<manu> [30]https://github.com/w3c/vc-data-model/issues/541
[30] https://github.com/w3c/vc-data-model/issues/541
<manu> PROPOSED: Issue #541 is addressed by PR #542, which
makes a non-substantive change that fixes a bug in the
specification related to JWT jti/sub values being swapped. This
is a non-substantive change because there were two conflicting
normative statements in the specification, the examples were
clearly the intent, and any reasonable implementer would have
implemented the feature correctly based on the existing JWT
encoding rules in the specification. The PR has been approved
by multiple parties as a non-substantive change and should be
merged. Issue #541 should be closed after the PR is merged.
[ no objection ]
RESOLUTION: Issue #541 is addressed by PR #542, which makes a
non-substantive change that fixes a bug in the specification
related to JWT jti/sub values being swapped. This is a
non-substantive change because there were two conflicting
normative statements in the specification, the examples were
clearly the intent, and any reasonable implementer would have
implemented the feature correctly based on the existing JWT
encoding rules in the specification. The PR has been approved
by multiple parties as a non-substantive change and should be
merged. Issue #541 should be closed after the PR is merged.
manu: that ends the list of issues with pending PRs ...
<stonematt> thank you, thank you, thank you to everyone!
<dlongley> +1
<DavidC> I will also be away next week so I might not be able
to attend either
burn: manu will be on vacation for the next week, so we expect
not to process spec issues next week; instead, focus on the
implementation guide and registry
... please do continue offline work on issues (outside of
calls)
adjourned
Summary of Action Items
Summary of Resolutions
1. [31]A JWT is not a Verifiable Credential as the data models
differ. A JWT can be used to secure a Verifiable Credential
as described in Section 6.3.1. The language related to
@context processing for JWT-based processors should be
clarified to note that dereferencing @context values is not
required, which is a non-substantive clarification to the
existing text in the specification. The IANA registration
for the vc and vp JWT claims should be separated into an
IANA Considerations section. Issue #520 should be closed
after the PR is merged.
2. [32]One of the goals of the Verifiable Credentials Data
Model specification is to define extensibility points in
the data model and achieve interoperability on the
extensibility points (not the extensions themselves). The
interoperability tests will focus on ensuring that the
minimum information exists in extensions to identify the
extension without needing to define each extension in
detail for this iteration of the Working Group. Defining
extensions to the base data model is outside of the scope
of the WG's charter. All features that the Working Group
deems at risk were marked before entering CR. No new
at-risk features have been identified after processing
issue #523, which should be closed with no changes to the
specification.
3. [33]The VCWG seeks to demonstrate interoperability at the
data model and extension points in the specification, not
the extensions themselves as the group is not chartered to
work on extensions. The VCWG has reviewed all conformance
statements, has implemented a test suite that tests all
required conformance statements in the specification, and
asserts that this approach is appropriate for a data model
specification. Section 5.3 should remain normative as it
contains a normative section 5.3.1. Section 5.3.1 should
remain normative. Other PRs are in process that clarify the
findings of this proposal and once they are made, issue
#524 should be closed.
4. [34]Editors will non-normatively elaborate on the rules
that ensure that the array of values associated with
@context should be in the expected order. Close issue #525
after the PR has been merged.
5. [35]Multiple non-normative commits and PRs (#475, #499)
have been written, reviewed and applied for this issue. The
WG does not believe that any more mis-characterized
normative terminology appears in non-normative sections.
Issue #394 should be closed.
6. [36]Issue #462 is addressed by PR #503, which makes
non-normative changes detailing type information stored in
a credential as requested by the reviewer. The PR has been
approved by multiple parties and has been merged. Issue
#462 should be closed.
7. [37]Issue #463 is addressed by PR #504, which makes
non-normative changes to updated the definition of an
entity requested by the reviewer. The PR has been approved
by multiple parties and has been merged. Issue #463 should
be closed.
8. [38]Issue #464 is addressed by PR #512, which makes
non-normative changes related to the subject of the
credential as requested by the reviewer. The PR has been
approved by multiple parties and has been merged. Issue
#464 should be closed.
9. [39]Issue #466 is addressed by PR #477, which makes minor
non-normative changes by changing "might perform" to
"performs" for certain roles as requested by the reviewer.
The PR has been approved by multiple parties and has been
merged. Issue #466 should be closed.
10. [40]Issue #471 is addressed by PR #507, which makes
non-normative changes pointing out that trust is bilateral
between issuers and verifiers as requested by the reviewer.
The PR has been approved by multiple parties (including the
reviewer), and has been merged. Issue #471 should be
closed.
11. [41]Issue #472 is addressed by PR #476, which makes
non-normative changes noting that consent isn't implied by
signatures on presentations as requested by the reviewer.
The PR has been approved by multiple parties and has been
merged. Issue #472 should be closed.
12. [42]Issue #481 is addressed by PR #508 and PR #509, which
make multiple non-normative changes to the definitions of
roles in the ecosystem as requested by the reviewer. The PR
has been approved by multiple parties and have been merged.
Issue #481 should be closed.
13. [43]Issue #485 is addressed by PR #519, which makes
non-normative changes noting that a JWK can also be used in
the place of an `issuer` property as requested by the
reviewer. The PR has been approved by multiple parties and
has been merged. Issue #485 should be closed.
14. [44]Issue #541 is addressed by PR #542, which makes a
non-substantive change that fixes a bug in the
specification related to JWT jti/sub values being swapped.
This is a non-substantive change because there were two
conflicting normative statements in the specification, the
examples were clearly the intent, and any reasonable
implementer would have implemented the feature correctly
based on the existing JWT encoding rules in the
specification. The PR has been approved by multiple parties
as a non-substantive change and should be merged. Issue
#541 should be closed after the PR is merged.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [45]scribe.perl version 1.154 ([46]CVS log)
$Date: 2019/04/16 17:24:24 $
[45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[46] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 April 2019 17:26:31 UTC