- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 31 May 2019 03:31:14 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/05/28-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Amy, Yancy and Dan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
28 May 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019May/0014.html
Attendees
Present
Amy_Guy, Andrei_Sambra, Brent_Zundel, Dan_Burnett,
Dave_Longley, Dmitri_Zagidulin, Ganesh_Annan,
Justin_Richer, Kaz_Ashimura, Ken_Ebert, Manu_Sporny,
Tzviya_Siegman, David_Chadwick, Jonathan_Holt,
Oliver_Terbu, Benjamin_Young, Matt_Stone, Kaliya_Young,
Yancy_Ribbens
Regrets
Chair
Dan_Burnett
Scribe
rhiaro, yancy, burn
Contents
* [3]Topics
1. [4]Describe plan for the call
2. [5]PR announcements
3. [6]Issue lightning round: close the issues we can
4. [7]Test Suite Issues and Discussion
5. [8]Implementation topics discussion
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<rhiaro> scribenick: rhiaro
Describe plan for the call
burn: last week was a good opportunity for implementors to
discuss issues that were important. We also have some CR and PR
processing to do
... We'll do PR and CR processing first, then switch to
implementors
... any changes?
PR announcements
<burn> [11]https://github.com/w3c/vc-data-model/pulls
[11] https://github.com/w3c/vc-data-model/pulls
manu: we have a number of PRs, gonna start at the bottom with
641
<burn> [12]https://github.com/w3c/vc-data-model/pull/641
[12] https://github.com/w3c/vc-data-model/pull/641
manu: there's a longstanding i18n PR in discussion. I have as a
result rewritten the i18n section, it's all nonnormative, but
it's now pulled in the jsonld wg, the rdf community, the ld
community, the i18n community the ?? communiety at ietf, iana,
it's gone off the rails.. but we're making good progress and
have another meeting with them on wednesday for coming up with
a mechanism for lang direction that works in json and jsonld
... there's a big discussion
... everything else is a fairly straightforward PR
... oliver and dave longley and david chadwick have weighed in
on some. Heads up for folks to look at some of them
... that's every single PR we need to close out the remaining
issues I believe. Only 2 issues right now that dno't have PRs
and those we may not end up doing PRs for them because the
problems people are raising are difficult for us to write spec
text to
... there may be one or two other PRs but as long as there are
no more issues these are the PRs that close the CR period
... I think that's it for the PRs, no others we need to review
... unless anyone else has specific ones they want to review
burn: there aren't any we can close now?
manu: what we need is review from folks
... we will propose closing the issues associated with the PRs,
but that's next
... as far as closing the PRs on the call, we just need other
peple to review
... we need two independant reviews, as soon as we get that we
can merge the PRs
burn: everyone please review so we can close them
Issue lightning round: close the issues we can
burn: There may be some that we can look back at that have a 7
day close mark but we haven't been able to close for some
reason. Maybe we can take a look at a couple of those. Some
might require a followon group statement because of additional
comments made after the resolution
... we might still be able to get some of those closed
manu: I was not able to prepare all of the proposals before the
call
... The first is issue 518
<manu> [13]https://github.com/w3c/vc-data-model/issues/518
[13] https://github.com/w3c/vc-data-model/issues/518
<manu>
[14]https://github.com/w3c/vc-data-model/issues?page=1&q=is%3Ai
ssue+is%3Aopen
[14] https://github.com/w3c/vc-data-model/issues?page=1&q=is:issue+is:open
manu: This was oliver asking about multiple subjects, david
chadwick said we should have an example with multiple subjects,
we all agreed, I put in a PR, davidchadwick said he'd rather
see the marriage cert thing so I will make that change
<manu> PROPOSAL: Issue #518 is resolved via PR #644, which adds
an example on multiple subjects to the specification. Close
issue #518 after the PR has been merged.
manu: any objections?
DavidC: I'm happy
burn: I hear no objections
RESOLUTION: Issue #518 is resolved via PR #644, which adds an
example on multiple subjects to the specification. Close issue
#518 after the PR has been merged.
<manu> [15]https://github.com/w3c/vc-data-model/issues/526
[15] https://github.com/w3c/vc-data-model/issues/526
manu: next is issue 526. The current link says verifiable
claims data model, we changed it to vc data model, all the
links needed to be updated, I put in a PR for that
<manu> PROPOSAL: Issue #526 is resolved via PR #645, which
updates the TR links in the specification. Close issue #526
after the PR has been merged.
burn: I've been trying to keep this open until right before PR,
it's a reminder for the chairs that as part of our closing out
process we need to remind the sysrec team
<manu> PROPOSAL: Issue #526 is resolved via PR #645, which
updates the TR links in the specification. Close issue #526
after the transition to Proposed Recommendation has occurred.
burn: I'll include it in the transition request and say part of
it is closing this issue
RESOLUTION: Issue #526 is resolved via PR #645, which updates
the TR links in the specification. Close issue #526 after the
transition to Proposed Recommendation has occurred.
burn: I hear no objections
<manu> [16]https://github.com/w3c/vc-data-model/issues/530
[16] https://github.com/w3c/vc-data-model/issues/530
manu: next is issue 530. This was basically a suggestion to
consolidate all the vc registries into a single registry
... that reminds me we have a resolution for this one
<manu> [17]https://github.com/w3c/vc-data-model/issues/584
[17] https://github.com/w3c/vc-data-model/issues/584
manu: moving on to the next one.. lots are done... next one is
issuanceDate
... this one was that ted raised, issuanceDate and
expirationDate are confusing and misleading. Had we more time
we would have renamed them to validFrom and validUntil but we
can't do that without going through another CR so I added spec
text that says we expect to transition to validFrom and
validUntil we're reserving those values and impelmentors should
be aware of that
... the only way for us to do it in a back compatible way and
we'll do it in the next revision of the spec
<manu> PROPOSAL: Issue #584 is resolved via PR #646, which
updates the specification with non-normative language noting
that the properties will change to validFrom and validUntil in
the future. Close issue #584 after the PR has been merged.
RESOLUTION: Issue #584 is resolved via PR #646, which updates
the specification with non-normative language noting that the
properties will change to validFrom and validUntil in the
future. Close issue #584 after the PR has been merged.
burn: any objections
... hearing no objections
<manu> [18]https://github.com/w3c/vc-data-model/issues/585
[18] https://github.com/w3c/vc-data-model/issues/585
manu: next is 585. This has to do with a request by davidc. The
question was how does a pure json implementor know what the
proper order of the contexts array should be
... we said it's the same way they know the proper order of
anything in any other json spec, which is that there's some
human readable document that says what the order should be.
greg said there's a jsonld 1.1 feature that lest you specify
the context in html, which is bad and was removed from the
spec. The PR that was introduced after that noted in the
implementation guide that if you want a human readable context
you can use conneg to achieve
that and there's now a section about conneg for human readable
documents that json developers could use to take one of those
urls, dump it into a web browser and get thee xpected order of
context values from that document
scribe: DavidC, I don't know if this works for you or not
DavidC: I haven't reviewed the text but I think the
implementation guide is a good place to put it. It affects us
in our implementation. I think that's a fair way of resolving
the problem
<manu> PROPOSAL: Issue #585 is resolved via commit
504c9c1189d060cc9f1deb2ff35507e1fbf3f282 to the Implementation
Guide, which advises JSON-LD Context publishers on how to
publish human readable contexts that advise on context order.
Issue #585 should be closed after a 7 day review period.
burn: objections?
RESOLUTION: Issue #585 is resolved via commit
504c9c1189d060cc9f1deb2ff35507e1fbf3f282 to the Implementation
Guide, which advises JSON-LD Context publishers on how to
publish human readable contexts that advise on context order.
Issue #585 should be closed after a 7 day review period.
burn: hearing no objections
<manu> [19]https://github.com/w3c/vc-data-model/issues/586
[19] https://github.com/w3c/vc-data-model/issues/586
<Justin_R> told you I wasn't all the way here 🤷♀️
manu: next issue 586. DavidC raised the issue of using jwts
with presentations. There have been a suggestion to add a
sentence, he put in a PR, the PR got reviews, looked good and
has been merged. I believe David your PR addresses the issue
you raised and so we should close this issue
DavidC: agreed
<manu> PROPOSAL: Issue #586 is addressed via PR #627, which
adds non-normative guidance wrt. using JWTs w/ presentations.
Issue #586 should be closed since the PR has been merged.
oliver: ?? presentation after PR is it still valid?
<jonathan_holt> I believe so, yes
manu: it should be, that might be a different PR?
... that's a different PR, this one has to do with saying an
example of a vc using a jwt is given in secton json web tokens.
Just shows you how to do a jwt based presentation
DavidC: basically adding a forward pointer into the spec
because when you read it it's not obvious
oliver: right okay thanks
manu: your other concern, we didn't intend to change anything
in the spec, jwt is still a valid way of doing a presentation
... nothing normative changed, it just got more specific
... any objections to that proposal?
RESOLUTION: Issue #586 is addressed via PR #627, which adds
non-normative guidance wrt. using JWTs w/ presentations. Issue
#586 should be closed since the PR has been merged.
burn: I don't hear any objections
<manu> [20]https://github.com/w3c/vc-data-model/issues/589
[20] https://github.com/w3c/vc-data-model/issues/589
burn: do we need a 7 day close on this or I should just close
it?
manu: we might as well mark it 7 day close and close it after 7
days to be consistent
... Next up is 589, json schema reference, DavidC noted that
the json schema reference we used is old and we had ad
iscussion about the right version to point to, there's a new
new new one at ietf when we had the discussion, it has expired
and they have published a new one that's not expired. We
updated it to the 2019 json schema spec in a way that will
always point you to the latest json schema spec at ietf, so
that's what pr 647 does
<manu> PROPOSAL: Issue #589 is addressed via PR #647 which
updates the non-normative reference to JSON Schema to a more
stable IETF URL. Issue #589 should be closed after the PR is
merged.
<jonathan_holt> is this the link?
[21]https://tools.ietf.org/html/draft-handrews-json-schema
[21] https://tools.ietf.org/html/draft-handrews-json-schema
ken: you said it'll always stay up to date and you're pointing
to json schema 2019, does that get updated or is it intended to
be 2019?
manu: it's strangely named, we created the reference in 2019.
there's no official version of json schema. What we do is point
to th elatest one that we know of and when new versions are
published at ietf the reader will be advised that there is a
new version at the top of the document
... what we're signalling is we reference the 2019 version non
normatively but htere may be a later version
... because we make no normative statements about it we can be
wishy washy about how we point to that document
burn: jonathan asked in irc, if this is the specific draft
manu: yes it's that link
<Zakim> Justin_R, you wanted to talk about IETF versions
Justin_R: to clarify how the ietf system works for people who
may not be familiar, the link that jonathan put in the chat
will always point to whatever the latest draft handrews json
schema verson is. If a draft 02 version were updated today
that's what the link would point to, it's not a stable content
url. As it's an informative reference I'd recommend the group
point to a specific version of that document as being
referenced if that type of long
term stability is what you're after
manu: I don't think we were trying to get to that specific typ
eof long term stability, we're trying to point to the latest of
whatever it is, thats' why we weren't specific
Justin_R: that implies that the requirement is to keep pace
with that in whatever state it is
manu: it's effecitvely make sure you're using the latest
version fo that spec. The hope is it'll eventually hit a
normative stable point, but it's not there yet. Our guidence is
make sure you're using the latest version, that's why we point
to that
... any objections to the proposal?
burn: hearning none
RESOLUTION: Issue #589 is addressed via PR #647 which updates
the non-normative reference to JSON Schema to a more stable
IETF URL. Issue #589 should be closed after the PR is merged.
<manu> [22]https://github.com/w3c/vc-data-model/issues/596
[22] https://github.com/w3c/vc-data-model/issues/596
manu: next is 596. Dave longley raised an issue that we had not
.. there was a discussion about having holder, saying who the
holder is in the presentation, we found an implementation needf
or that, DavidC also wanted that feature. we've resolved holder
in a non-normative way in the main spec. We call it out but we
don't say it's required or anything like that. The text is
wishy washy and we expect that text to firm up in the next
revision of the
spec
scribe: That's via pr 648
<manu> PROPOSAL: Issue #596 is addressed via PR #648, which
adds non-normative text describing the holder property. Issue
#596 should be closed after the PR is merged.
RESOLUTION: Issue #596 is addressed via PR #648, which adds
non-normative text describing the holder property. Issue #596
should be closed after the PR is merged.
burn: hearing no objections
<manu> [23]https://github.com/w3c/vc-data-model/issues/600
[23] https://github.com/w3c/vc-data-model/issues/600
manu: next 600 which was an issue dmitri found in the examples
during the test suite, pr 601 addresses it and has been merged
... the basic issue is that there was a .. verifiable
presentations.. does this make the subtype mandatory or
optional?
dmitriz: I believe the spec has it as mandatory
dlongley: the spec is confusing on this point and it can be
read as mandatory or not, we were having a discussion about
that somehwere. I think it should not be mandatory. I would
expect people to have to create a throw away type that doesn't
have any semantics in the majority of cases
manu: this adds credential mangement presentation to every
single example
dlongley: proves my point there's no reason to have an
additional type at this stage. Don't believe it would be
normative right now
manu: the spec says the type property is required and expresses
the type of presentation, so that doesn't mean that it's
mandatory...
dlongley: the spec says all credential presentations must
specify or be associated with additional more narrow types
... in the types section 4.3
manu: for verifiable presentation we say optionally a more
specific verifiable presentation type, it's optional in the
spec
... the spec is contradictory, so we can change it without it
being a non normative change
... in two places we say the subtype is optional and in this
case I think it says you have to specify more narrow types but
it says it for everything whereas in the case of presentations
we said it's optional
DavidC: that's correct, I agree with Dave becuase the
presentation is a set of VCs. Where you need more narrow types
if if you start to put your own params in there like term sof
use then it would becom ea more narrow verifiable presentation
jonathan_holt: for the schema, the type is in the string or
array of strings? andthen to clarify, is there precedence of
the meaning if it's unordered?
manu: can it be a string or an array? Yes it can be either.
... strings that effectively map to URLs.
... I don't know what you mean by precedent. It's an unordered
set so order doesn't matter
jonathan_holt: similar for context if it's unordered and the
same name is used twice with a different pointer is there
potential confusion for the meaning?
manu: there is for context but not for type
<Zakim> brent, you wanted to say that a presentation must be
associated with a narrower type.
brent: the way the spec reads it doesn't even say that a
presentation must have multiple types, it says the stuff in the
presentation needs to be associated with a type. It's even more
confusing. We really need to change it.
manu: we probably need to raise a new issue on this, it's not
clear to me which text changes and what triggers a normative
change and we're not goign to be able to figure it out on the
call
<oliver> who is raising the new issue?
going back to issue 600, dmitri's change sets a type and a
subtype across all the examples which are non normative so we
can rip that out later if we need to after this other
discussion. But 600 is aaddressed by 601. Let's merge it and
raise a new issue
<manu> PROPOSAL: Issue #600 is addressed via PR #601, which
makes non-normative changes to the examples. Close issue #600
after the PR has been merged.
brent: I am raising it right now
burn: any objections to the proposal?
RESOLUTION: Issue #600 is addressed via PR #601, which makes
non-normative changes to the examples. Close issue #600 after
the PR has been merged.
burn: hearing none
<manu> [24]https://github.com/w3c/vc-data-model/issues/602
[24] https://github.com/w3c/vc-data-model/issues/602
burn: if it's related to this one you might want to include a
reference in your issue back to 600 brent
manu: issue 602 is raised by tony he says section 3.1 is non
normative but contains the word must in lower case
... typically lowercase musts shoulds and mays are not
normative, but tony wanted us to change it, this resulted in a
discussion with the editors of respec and a w3c wide discussion
... so now every w3c specification going forward is going to
say dont' pay attention to lowercase musts, only uppercase
matters
... tony said that's not good enough, please change it so
you're not useing lowercase musts shoulds and mays in the
document
<manu> PROPOSAL: Issue #602 is addressed via PR #649, which
removes the non-normative "must" in favor of "is expected to".
Issue #602 should be closed once the PR is merged.
burn: objections?
RESOLUTION: Issue #602 is addressed via PR #649, which removes
the non-normative "must" in favor of "is expected to". Issue
#602 should be closed once the PR is merged.
burn: hearing none
... I consider this an example of how this working group of how
this wg has gone above and beyond its requirements in
addressing external concerns
<manu> [25]https://github.com/w3c/vc-data-model/issues/604
[25] https://github.com/w3c/vc-data-model/issues/604
manu: next issue 604, an issue that tony raised about @context
and whether processing was required or not. Adds clarity, brent
and ted suggested some changes, 3 PRs went in to address this
and they've all been merged
... they say you don't need a jsonld processor but if you're
just using json the contexts are in the order you expect themto
be in. If you do that you're good wrt the sematnic meaning and
property value pairs and short url values
<dlongley> to be clear -- everyone (JSON/JSON-LD) has to make
sure the order of the contexts is proper and the PR that was
merged says this.
<manu> PROPOSAL: Issue #604 is addressed via PR #630, which
adds non-normative text to clarify the processing requirements
around @context. Multiple other PRs were also made to address
this issue. Issue #604 should be closed after a 7 day wait
period.
DavidC: about the fact the person who raised the issue tends to
raise issues but never comments on if the resolution is good,
and then raises another issue. The person who raised the issue
could be invited to comment on the PR so we don't end up going
through it again
burn: there's a 7 day time preiod, if we do not receive
objections in that time period I can go ahead and close it
... valid comments can cause a continued discussion but if it's
not going anywhere we can find a way to close
... all of these external issues have come in after the review
period
... we are allowed to say which ones we will address and which
ones we will not
... it's always nice to address the ones you can, and its' good
that the group is doing that, but if we get some that don't
seem to be getting resolved it is fine for the group to say
sorry, this came in after the comment period, we made every
effort we can but this will not be resolved for this version
<Zakim> burn, you wanted to remind group that we can refuse to
address these and later external issues
ken: on the pr 630 it introduces an uppercase MUST that is a
normative change
manu: I noticed that, I believe it does it in a way that is
inline with what the other spec text was already saying,
because of that it's a non-normative change. The addition of
the MUST doens't change any implementation, it's a
clarification of what the spec should have said before
ken: makes sense
manu: any objections?
burn: I would say issue 604 WILL BE closed after a 7 day wait
period
... any other comments?
RESOLUTION: Issue #604 is addressed via PR #630, which adds
non-normative text to clarify the processing requirements
around @context. Multiple other PRs were also made to address
this issue. Issue #604 will be closed after a 7 day wait
period.
burn: hearing none
manu: ken, thanks for eagle-eyeing that change
... next up is 605
... I've got 15 more of these... time check?
<brent> I want to cover the issues
burn: we don't have as much time for implementations. THi sis
still the number 1 priority, we've gotta keep moving these
forward
... anyone who objects to continuing with these and then moving
on to implementation?
... We'll continue, however we need a new scribe \o/
<scribe> scribenick: yancy
<manu> [26]https://github.com/w3c/vc-data-model/issues/605
[26] https://github.com/w3c/vc-data-model/issues/605
manu: issue raised by tony
... 605 is addressed via 650
<manu> PROPOSAL: Issue #605 is addressed via PR #650, which
makes a non-normative change to the spec regarding changing a
lowercase "must not" to a "is expected to not". Issue #605
should be closed after the PR is merged.
burn: objections?
RESOLUTION: Issue #605 is addressed via PR #650, which makes a
non-normative change to the spec regarding changing a lowercase
"must not" to a "is expected to not". Issue #605 should be
closed after the PR is merged.
<manu> [27]https://github.com/w3c/vc-data-model/issues/606
[27] https://github.com/w3c/vc-data-model/issues/606
manu: resolved
... another issue raised by tony
<manu> PROPOSAL: Issue #606 is addressed via PRs #616, #628,
and #651 by making non-normative clarifications to the
specification. Issue #606 should be closed after all associated
PRs have been merged.
manu: any objections?
RESOLUTION: Issue #606 is addressed via PRs #616, #628, and
#651 by making non-normative clarifications to the
specification. Issue #606 should be closed after all associated
PRs have been merged.
burn: hears none
<manu> [28]https://github.com/w3c/vc-data-model/issues/608
[28] https://github.com/w3c/vc-data-model/issues/608
manu: pr went in and ted wrote the pr and it's been merged
<manu> PROPOSAL: Issue #608 is addressed via PR #631 which adds
non-normative clarification around the SHOULD of concern to the
reviewer. Issue #608 will be closed after a 7 day wait period.
manu: objections?
RESOLUTION: Issue #608 is addressed via PR #631 which adds
non-normative clarification around the SHOULD of concern to the
reviewer. Issue #608 will be closed after a 7 day wait period.
burn: hears none
<manu> [29]https://github.com/w3c/vc-data-model/issues/609
[29] https://github.com/w3c/vc-data-model/issues/609
manu: next up is issue 609
... we changed from jwt to jws. we now refer to jws.
<manu> PROPOSAL: Issue #609 is addressed via PR #652, which
makes a non-normative clarification to the specification
regarding JWS. Issue #609 should be closed after the PR is
merged.
<manu> PROPOSAL: Issue #609 is addressed via PR #652, which
makes a non-normative clarification to the specification
regarding JWS. Issue #609 should be closed after the 7 day
review period and after the PR is merged.
RESOLUTION: Issue #609 is addressed via PR #652, which makes a
non-normative clarification to the specification regarding JWS.
Issue #609 should be closed after the 7 day review period and
after the PR is merged.
burn: as soon as we agree on the resolution we drop it in
<manu> [30]https://github.com/w3c/vc-data-model/issues/610
[30] https://github.com/w3c/vc-data-model/issues/610
manu: tony says what's the definition of a decentralized
document
... lots of back and forth
... we're just talking about decentralized identifiers in
general
... proposal is is 610
<manu> PROPOSAL: Issue #610 is addressed via PR #618, which
makes non-normative clarifications on the term "decentralized
identifier document". Issue #610 will be closed after the 7 day
wait period.
burn: any objections?
RESOLUTION: Issue #610 is addressed via PR #618, which makes
non-normative clarifications on the term "decentralized
identifier document". Issue #610 will be closed after the 7 day
wait period.
<manu> [31]https://github.com/w3c/vc-data-model/issues/611
[31] https://github.com/w3c/vc-data-model/issues/611
manu: next up is 611
... also raised by tony
... it's a wording concern around proofs
... ted reworded and tony said that's better
... didn't say he's ok said he's better
<manu> PROPOSAL: Issue #611 is addressed via PR #617, which
makes non-normative clarifications to the specification
regarding proof details and mechanism. Issue #611 will be
closed after the 7 day wait period.
brent: would it be possible to change the proposal to change
now
... since 7 days already passed
burn: it was merged and after that the 7 day closed
<manu> PROPOSAL: Issue #611 is addressed via PR #617, which
makes non-normative clarifications to the specification
regarding proof details and mechanism. Issue #611 will be
closed immediately since the 7 day wait period has expired.
burn: it's been more than 7 days since the merge
manu: reworeded the proposal
burn: hears none
RESOLUTION: Issue #611 is addressed via PR #617, which makes
non-normative clarifications to the specification regarding
proof details and mechanism. Issue #611 will be closed
immediately since the 7 day wait period has expired.
<manu> [32]https://github.com/w3c/vc-data-model/issues/612
[32] https://github.com/w3c/vc-data-model/issues/612
<manu> PROPOSAL: Issue #612 is addressed via PR #614, which
rewords the text of concern in a non-normative way. Issue #612
should be closed after 7 days from when the PR was merged.
RESOLUTION: Issue #612 is addressed via PR #614, which rewords
the text of concern in a non-normative way. Issue #612 should
be closed after 7 days from when the PR was merged.
<manu> [33]https://github.com/w3c/vc-data-model/issues/613
[33] https://github.com/w3c/vc-data-model/issues/613
<manu> PROPOSAL: Issue #613 is addressed via PR #615, which
makes non-normative changes to expiration to clarify its usage.
Issue #613 should be closed immediately.
burn: objections?
RESOLUTION: Issue #613 is addressed via PR #615, which makes
non-normative changes to expiration to clarify its usage. Issue
#613 should be closed immediately.
<manu> [34]https://github.com/w3c/vc-data-model/issues/621
[34] https://github.com/w3c/vc-data-model/issues/621
manu: doesn't think we can close this one
... conversation turned into should the values in a credential
be arrays
... this approach has already been tried multiple times for a
right hand value
... you should not make the assumption that's it's a single
value or an array
... waiting to hear back on if it's acceptable
... we'll just add non-normative text
<manu> [35]https://github.com/w3c/vc-data-model/issues/622
[35] https://github.com/w3c/vc-data-model/issues/622
manu: moving on
brent: the id property was left out of the json
<manu> PROPOSAL: Issue #622 is resolved via PR #623, which
fixes a bug in the JSON-LD context. Issue #622 should be closed
immediately.
<manu> manu: dmitri, yancy, is it ok if we close immediately?
<manu> dmitriz: No objections.
<manu> yancy: No objections.
RESOLUTION: Issue #622 is resolved via PR #623, which fixes a
bug in the JSON-LD context. Issue #622 should be closed
immediately.
burn: a variety has come down to one of these three topics.
<manu> [36]https://github.com/w3c/vc-data-model/issues/632
[36] https://github.com/w3c/vc-data-model/issues/632
<manu> [37]https://github.com/w3c/vc-data-model/issues/633
[37] https://github.com/w3c/vc-data-model/issues/633
<manu> [38]https://github.com/w3c/vc-data-model/issues/634
[38] https://github.com/w3c/vc-data-model/issues/634
burn: when it comes to PR I can point to these three issues
... but at least they are captured here
<manu> [39]https://github.com/w3c/vc-data-model/issues/642
[39] https://github.com/w3c/vc-data-model/issues/642
burn: where the group believes it's made appropirate
determination over tonys objections
manu: someone said has someone thought about protocol buffers
... we have put more into cbor than char buffers
... encode the app as whatever and then deserialized it
... and then just pick a transformation rule for @context
... that's the most we can do in the implementation guidance
... that's it
burn: we should thank manu
... with luck we should be able to close all these
<dlongley> +1 thanks to manu and everyone for helping out!
manu: thanks to everyone invloved
burn: we're not done yet but we are close
Test Suite Issues and Discussion
burn: moving on to the implementation phase
<burn> [40]https://github.com/w3c/vc-test-suite/issues
[40] https://github.com/w3c/vc-test-suite/issues
burn: turns it over to dmitriz
dmitriz: from the top in reverse chronologic order
... ken brought up a point that presentations need their own
context
... says he thinks context is implied
... others said the vcs inside a credential need their own
context
<dlongley> +1... :)
ken: agrees strongly with daves objections
... we also need to raise a correspondant issue to make example
is the text
... can make those changes and submit an issue to the data
model
dmitriz: recent PR the Oliver opened for test-suite sequence
diagram
... will look at it asap
... at first glance it looks great
... aside from that nothing new
... a number of documentation issues
... qustion to brent about 28
brent: the command fails to run the report
... if I take the text and paste in it fails
dmitriz: command runs for me
brent: you and I get together and work through that
<burn> scribenick: burn
yancy: if you and brent find issues please post for the rest of
us
dmitriz: will do
<yancy> dmitriz: the other issue
<scribe> scribenick: yancy
dmitriz: the test report should be broken up into different
catagories
... is working on it as stated
<Zakim> manu, you wanted to mention work that Andrew Jones is
doing on #30 to dmitriz :)
dmitriz: already implemented by andrew jones
manu: we need to figure out to simplify that stuff
dmitriz: code already written should be easy to lift
Implementation topics discussion
burn: anything else beforfe we switch to generic topics
<burn> scribenick: burn
<gannan> yancy: which parser are you using?
recent change to context has brought up issue with JSON-LD
processor. Others should watch out for this
manu: which one are you using?
yancy: ruby
manu: probably Gregg Kellogg's. Should be compliant. We can
help with that.
yancy: just wanted others to be aware. hopefully there is a
quick fix there.
dlongley: Gregg just fixed all of that, so just waiting on a
new release
<scribe> scribenick: yancy
manu: general question
... do people like it?
... using same design pattern with other projects
ken: my comment would be getting start is the weakest part of
the test-suite
<brent> +1
ken: having trouble persuading others
... updating the documentation would be more than sufficient
brent: beginning to implement test-suit begins to shift my
mental model
... once my brain shifted to that point things became easy
... wasn't sure what to be doing on his part
... it is a weird way of running test-suits
manu: think we can do protocol testing in the same way
... looking for suggestions if others have any for a better
test-suit
... maybe did resolution is the first thing we test
... if we feel like this works well, then we have some
repeatable tooling
... now is the time to let us know
ken: thought of something else the would be helpful is to make
the suit more modular to make quicker turn cycles
manu: yep maybe raise an issue
dmitriz: I was somewhat sceptical of the datamodel test-suit
... wants to echo what was said that its a weird mental shift
burn: still doesn't like the idea of a test-suit for the data
model
... you're right it's to test the implementation of the spec
<burn> scribenick: burn
yancy: much of what the test suite does is to test which parts
of the JSON model are syntactically accurate. Would be good to
make that clear to implementers.
<scribe> scribenick: yancy
<burn> scribenick: burn
yancy: maybe something like JSON schema. a JSON object that has
name of key and then true for requirements. Test suite just
transforms from English. People may be looking at test suite
directly and might be nirce to have a better map.
<scribe> scribenick: yancy
<jonathan_holt> I like json-schema and I'm working on a
document
davidc: update on driver license
... update to suggest that vc becomes a standard for encoding
... has not had any feedback
... would be nice to tell them a little about our standard
davidc
davidc: will be a big win
<brent> I would be willing to review a draft primer as well
<manu>
[41]https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master
/topics-and-advance-readings/verifiable-credentials-primer.md
[41] https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/topics-and-advance-readings/verifiable-credentials-primer.md
manu: just there is vc primer that's old at this point but we
did create something
... happy to look for it
Davidc: please email it to me
manu: link is pasted
burn: anything else for today?
... next week we will have a nother 2 hour call
Summary of Action Items
Summary of Resolutions
1. [42]Issue #518 is resolved via PR #644, which adds an
example on multiple subjects to the specification. Close
issue #518 after the PR has been merged.
2. [43]Issue #526 is resolved via PR #645, which updates the
TR links in the specification. Close issue #526 after the
transition to Proposed Recommendation has occurred.
3. [44]Issue #584 is resolved via PR #646, which updates the
specification with non-normative language noting that the
properties will change to validFrom and validUntil in the
future. Close issue #584 after the PR has been merged.
4. [45]Issue #585 is resolved via commit
504c9c1189d060cc9f1deb2ff35507e1fbf3f282 to the
Implementation Guide, which advises JSON-LD Context
publishers on how to publish human readable contexts that
advise on context order. Issue #585 should be closed after
a 7 day review period.
5. [46]Issue #586 is addressed via PR #627, which adds
non-normative guidance wrt. using JWTs w/ presentations.
Issue #586 should be closed since the PR has been merged.
6. [47]Issue #589 is addressed via PR #647 which updates the
non-normative reference to JSON Schema to a more stable
IETF URL. Issue #589 should be closed after the PR is
merged.
7. [48]Issue #596 is addressed via PR #648, which adds
non-normative text describing the holder property. Issue
#596 should be closed after the PR is merged.
8. [49]Issue #600 is addressed via PR #601, which makes
non-normative changes to the examples. Close issue #600
after the PR has been merged.
9. [50]Issue #602 is addressed via PR #649, which removes the
non-normative "must" in favor of "is expected to". Issue
#602 should be closed once the PR is merged.
10. [51]Issue #604 is addressed via PR #630, which adds
non-normative text to clarify the processing requirements
around @context. Multiple other PRs were also made to
address this issue. Issue #604 will be closed after a 7 day
wait period.
11. [52]Issue #605 is addressed via PR #650, which makes a
non-normative change to the spec regarding changing a
lowercase "must not" to a "is expected to not". Issue #605
should be closed after the PR is merged.
12. [53]Issue #606 is addressed via PRs #616, #628, and #651 by
making non-normative clarifications to the specification.
Issue #606 should be closed after all associated PRs have
been merged.
13. [54]Issue #608 is addressed via PR #631 which adds
non-normative clarification around the SHOULD of concern to
the reviewer. Issue #608 will be closed after a 7 day wait
period.
14. [55]Issue #609 is addressed via PR #652, which makes a
non-normative clarification to the specification regarding
JWS. Issue #609 should be closed after the 7 day review
period and after the PR is merged.
15. [56]Issue #610 is addressed via PR #618, which makes
non-normative clarifications on the term "decentralized
identifier document". Issue #610 will be closed after the 7
day wait period.
16. [57]Issue #611 is addressed via PR #617, which makes
non-normative clarifications to the specification regarding
proof details and mechanism. Issue #611 will be closed
immediately since the 7 day wait period has expired.
17. [58]Issue #612 is addressed via PR #614, which rewords the
text of concern in a non-normative way. Issue #612 should
be closed after 7 days from when the PR was merged.
18. [59]Issue #613 is addressed via PR #615, which makes
non-normative changes to expiration to clarify its usage.
Issue #613 should be closed immediately.
19. [60]Issue #622 is resolved via PR #623, which fixes a bug
in the JSON-LD context. Issue #622 should be closed
immediately.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [61]scribe.perl version 1.154 ([62]CVS log)
$Date: 2019/05/30 18:28:03 $
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[62] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 30 May 2019 18:32:19 UTC