- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 20 May 2019 13:38:06 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/05/14-vcwg-minutes.html
Thanks a lot for taking these minutes, Ken!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
14 May 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019May/0004.html
Attendees
Present
Allen_Brown, Andrei_Sambra, Brent_Zundel,
Charles_McCathie_Nevile, Dan_Burnett, Dave_Longley,
David_Chadwick, Dmitri_Zagidulin, Ganesh_Annan,
Jonathan_Holt, Justin_Richer, Kaz_Ashimura, Ken_Ebert,
Manu_Sporny, Sercan_Kum, Ted_Thibodeau, Tim_Tibbals,
Yancy_Ribbens, Oliver_Terbu
Regrets
Benjamin_Young
Chair
Dan_Burnett
Scribe
ken
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]Implementation or other topics
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<manu> scribenick: ken
Describe plan for the call
burn: Today's plan is the same as last week.
... If we don't use all the time, we'll discuss forward looking
plans.
... David, the topic you've raised, does it need discussion to
exit CR?
DavidC: No it is not a CR issue.
PR announcements
<burn> [10]https://github.com/w3c/vc-data-model/pulls
[10] https://github.com/w3c/vc-data-model/pulls
manu: Thanks to Ted on help with the current issues.
... Also Brent, DavidC.
... These new issues are coming in after the CR period. It is
our choice on how to deal with them.
... Some may be deferred.
burn: I like the conversations that have happened.
... It is not a requirement.
<manu> [11]https://github.com/w3c/vc-data-model/pull/577
[11] https://github.com/w3c/vc-data-model/pull/577
<manu> [12]https://github.com/w3c/vc-data-model/pull/624
[12] https://github.com/w3c/vc-data-model/pull/624
manu: Those following this issue. We have been waiting for
additional input.
... Ken added a diagram. I have reviewed it along with Ted and
DavidC.
... David raised a concern without specific suggestions. We may
still need to tweak 624.
<manu> [13]https://github.com/w3c/vc-data-model/pull/587
[13] https://github.com/w3c/vc-data-model/pull/587
manu: Yancy raised this issue. Dave L. has been working to
correct some bugs with the json-ld processors.
... This is resulting a cleaner context for VC.
... This may take a few weeks.
DavidC: I would like to add text to the diagram to show that
transfer is not the normal use cases.
<manu> [14]https://github.com/w3c/vc-data-model/pull/599
[14] https://github.com/w3c/vc-data-model/pull/599
manu: Yes. please suggest the change.
<manu> [15]https://github.com/w3c/vc-data-model/pull/599
[15] https://github.com/w3c/vc-data-model/pull/599
manu: Disputes section makes no normative statements. It was
suggested to move the section.
... Are the objections to this move substantive?
DavidC: I thought the conformance statement was originally
missing, but it would result in a new CR.
... Could we use "SHOULD"?
manu: No this would not work. We could add suggestions in the
implementation guide.
... This would allow us to update this as more discussion
occurs in the working group.
... Then add it to the spec in the next version.
... That allows for the time to decide what it should really
look like.
... This avoids errors.
DavidC: In the implementation guide can we say "must"?
manu: Currently there are no normative statement in the
implementation guide, but we could.
<Zakim> burn, you wanted to require PR in impl. guide
burn: When we say, "Can we put 'this'
" in the implementation guide?"
scribe: it is us to do it?
... "MUST" in the implementation guide is confusing.
DavidC: It is worse in my opinion to have all the "disputes"
section in the implementation guide.
<manu> [16]https://github.com/w3c/vc-data-model/pull/599
[16] https://github.com/w3c/vc-data-model/pull/599
manu: Please raise a PR.
<manu> [17]https://github.com/w3c/vc-data-model/pull/614
[17] https://github.com/w3c/vc-data-model/pull/614
<TallTed> valid expression for implementation guide is
"implementations are expected to..." or "existing
implementations do x, y, z"
manu: Ted please fix the merge conflict.
<manu> [18]https://github.com/w3c/vc-data-model/pull/619
[18] https://github.com/w3c/vc-data-model/pull/619
<burn> Thx Ted, good suggestions
manu: DaveL mentioned the examples are wrong.
<manu> [19]https://github.com/w3c/vc-data-model/pull/623
[19] https://github.com/w3c/vc-data-model/pull/623
manu: Brent made some request for changes that DaveL made. It
will be merged.
Dmirtriz: Is it possible to make the changes now, because
implementors are experiencing difficultly.
<manu> [20]https://github.com/w3c/vc-data-model/pull/624
[20] https://github.com/w3c/vc-data-model/pull/624
manu: done.
<manu> [21]https://github.com/w3c/vc-data-model/pull/625
[21] https://github.com/w3c/vc-data-model/pull/625
<chaals> [+1 to having merged 623 now]
manu: Needs another review
<manu> [22]https://github.com/w3c/vc-data-model/pull/626
[22] https://github.com/w3c/vc-data-model/pull/626
<TallTed> manu - 614 ready to merge.
manu: Also needs another review
<manu> [23]https://github.com/w3c/vc-data-model/pull/627
[23] https://github.com/w3c/vc-data-model/pull/627
manu: Needs another review.
DavidC: It also resolves 586.
manu: Back to burn.
Issue lightning round: close the issues we can
manu: We are going to process CR exits first.
... Then new issues to make sure we have a plan.
<DavidC> It also resolves issue 586
<manu>
[24]https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%
3Aissue+milestone%3ACR-Exit
[24] https://github.com/w3c/vc-data-model/issues?q=is:open+is:issue+milestone:CR-Exit
<DavidC> not 626
I misheard you David
<manu>
[25]https://github.com/w3c/vc-data-model/issues?page=2&q=is%3Ao
pen+is%3Aissue+milestone%3ACR-Exit
[25] https://github.com/w3c/vc-data-model/issues?page=2&q=is:open+is:issue+milestone:CR-Exit
<DavidC> no problem ken
burn: There are some new ones too
<manu> [26]https://github.com/w3c/vc-data-model/issues/436
[26] https://github.com/w3c/vc-data-model/issues/436
<manu>
[27]https://github.com/w3c/vc-data-model/issues/436#issuecommen
t-492054772
[27] https://github.com/w3c/vc-data-model/issues/436#issuecomment-492054772
manu: Natural language features has a proposal.
... The goals are to create a solution for json-ld and json.
... json is difficult to do natural language.
... We are looking for something to help json perform
internationalization.
... Direction (hebrew, etc.) is an issue.
burn: Avon was at the conference and we discussed how there is
a problem with json.
... He said there is a json-ld issue raised on this re: rdf to
fix text direction.
... Richard Ashida agrees with him.
<chaals> [I also know what he is talking about and agree with
Manu]
Chaals: silence
<chaals> [+1 to Manu on the approach for text direction]
manu: We can fix it in the rdf for text direction.
... We can push this design pattern in our data model.
... Some implementations may not choose full rdf.
<burn> Works for me
manu: This should not delay the VC spec.
... We can add statements in the implementation guide.
... Then push the json-ld 1.1 group to include it.
<Zakim> dlongley, you wanted to say there's a signature issue
dlongley: What do we do with canonicalizing data?
manu: We could drop it.
... The text direction should not change the meaning of what's
signed.
<Zakim> dlongley, you wanted to say other solutions included
new language tags
<chaals> [Hmmm. Worth thinking harder on this… I think there
are a few ways, not sure that dropping it is ideal but it
probably doesn't change meanings as a rule]
dlongley: There may have difference in meaning with different
text directions. It could affect signatures.
manu: The details matter and we need to discuss this with I18N.
burn: More offline discussion is needed.
DavidC: We should specify what the defaults are.
manu: There is no default language. Direction is unspecified.
... Other items that need discussion?
... Oliver?
Oliver is not on the call.
manu: New issues.
<manu> [28]https://github.com/w3c/vc-data-model/issues
[28] https://github.com/w3c/vc-data-model/issues
<manu> [29]https://github.com/w3c/vc-data-model/issues/585
[29] https://github.com/w3c/vc-data-model/issues/585
manu: DavidC mentioned that a human readable context would help
implementors.
... There is a new feature in json-ld 1.1 under review.
... DavidC, there is a possibility to content negotiate.
... We could add something about this regarding implementors
providing this type of service.
DavidC: Could we provide a new property?
<chaals> [You could add a field to the context that explicitly
points to something… but I am of those whose experience
suggests that assuming people who publish contexts can do
content-negotiation is doomed to fail]
manu: That would be a json-ld 1.1 item.
<Justin_R> I'm with DavidC for this
manu: It is out of scope for this group.
DavidC: Can we add something to the implementation guide.
manu: OK.
<TallTed> "to suggest how one might publish..."
<chaals> [We could do it. But if we do it differently for every
kind of context document, that's a bad idea. So it should go
from us to JSON-LD group as a requirement and be done there]
<manu> [30]https://github.com/w3c/vc-data-model/issues/586
[30] https://github.com/w3c/vc-data-model/issues/586
manu: Using JWTs with presentation.
DavidC: It has a PR
<manu> [31]https://github.com/w3c/vc-data-model/issues/589
[31] https://github.com/w3c/vc-data-model/issues/589
manu: DavidC suggested an update to the json schema.
... It is a spec that has little active support.
<Justin_R> Correction: there is no RFC, just an ID draft
manu: We should point to the RFC that is out of date.
<Justin_R> (unless I'm missing something)
manu: Anyone with strong feelings?
Ted: We resolved to do that last week.
<manu> [32]https://github.com/w3c/vc-data-model/issues/596
[32] https://github.com/w3c/vc-data-model/issues/596
manu: dlongley said that it would be useful to have a holder
property in the implementation guide.
... Reserving the name is a non-normative change.
... That way someone can express the holder property in a
presentation.
burn: Reserving happens in the spec, right?
manu: In a non-normative way.
burn: Yes.
DavidC: Put the language back that said "MAY".
manu: That would be a normative change.
<TallTed> something like "The WG anticipates that the holder
property may be used in future; please reserve this property
for this use..." which also implies "if you use it now, use it
this way"
<Zakim> Justin_R, you wanted to discuss substantive/normative
change
burn: If we say where and how it should be used, that would be
a normative change.
JustinR: This is already in the data model.
manu: If that is true, you are correct.
JustinR: The only way is to make a normative change or have a
registry.
DavidC: It is in an example.
JustinR: That is not normative.
... Expectations of nice behavior isn't realistic.
manu: A normative change would result in a new CR.
<Zakim> burn, you wanted to correct justin on this - we can
request that implementers avoid using it
JustinR: Make it normative or take it out?
<chaals> [opinion on this is +1 to DanB]
<manu> +1 to DanB
<TallTed> meta - we REALLY should be tracking how many "this
would force another CR which we're out of time to do, so we
can't do that, even though it's really the best thing to do"
we're hitting to drop on W3M's desks. the current process hurts
everyone.
burn: It is better to non-normatively indicate that "holder" is
likely to be added.
<Justin_R> -1 for reasons previously stated
manu: Any objections?
jonathon_holt: Does this require a new context?
manu: yes
<burn> hmm, not sure about putting it in context
<DavidC> disputes
jonathon_holt: Is there a future terms field?
manu: No. We just include the holder term.
DavidC: Does this work for "disputes"?
manu: It could.
... This could turn into a PR to grab all of the reserved
terms.
... Any objections?
burn: I don't object. I am concerned re: the context reserved
strategy.
manu: I think it would be applied to all implementations the
same way.
... That is why order matters in the contexts.
burn: I think this should go into a non-normative PR.
<TallTed> I wonder why "disputes" is needed, per se. Any VC
should be able to reference another VC (by its ID); VC-2 might
be "disputing" or "modifying" or "extending" or "revoking" or
... VC-1.
<manu>
[33]https://github.com/w3c/vc-data-model/issues/596#issuecommen
t-492273300
[33] https://github.com/w3c/vc-data-model/issues/596#issuecomment-492273300
<manu> [34]https://github.com/w3c/vc-data-model/issues/600
[34] https://github.com/w3c/vc-data-model/issues/600
manu: Ted is correct, but DavidC is looking for the credential
type.
<manu> [35]https://github.com/w3c/vc-data-model/issues/602
[35] https://github.com/w3c/vc-data-model/issues/602
manu: Dmitriz have you addressed this in your PR?
Dmitriz: Yes.
manu: This contains a
... must.
<manu> "To be able to trust claims, more information must be
added." change to "To be able to trust claims, more information
is expected to be added to the graph."
burn: I like to avoid the use of "must" because is confuses
implementors with "MUST"
manu: We can do that.
... Ted suggested we refer to the RFC
<manu>
[36]https://github.com/w3c/vc-data-model/issues/602#issuecommen
t-492274555
[36] https://github.com/w3c/vc-data-model/issues/602#issuecomment-492274555
<TallTed> note -- RFC8174, not his typo of 8172
ken says ";)"
manu: The RFC says that only uppercase is normative.
<manu> [37]https://github.com/w3c/vc-data-model/issues/604
[37] https://github.com/w3c/vc-data-model/issues/604
manu: This is about context. Chaals had the right suggestion.
Brent suggestion has a lot of agreement.
<brent_> +1
<manu> [38]https://github.com/w3c/vc-data-model/issues/605
[38] https://github.com/w3c/vc-data-model/issues/605
manu: None of these are CR issues. They are all post-CR.
<manu> [39]https://github.com/w3c/vc-data-model/issues/606
[39] https://github.com/w3c/vc-data-model/issues/606
manu: Suggestion is to make a change to remove lowercase must.
... Reviewer suggested "In 4.2 it doesn't say that identifiers
are mandatory or optional"
... I think that it is clear to most implementors.
Ted: Can. we link to the section?
manu: Yes.
BrentZ: I already. fixed this in my PR.
burn: I don't know if Tony saw the update from BrentZ when he
made his last comment.
<manu>
[40]https://github.com/w3c/vc-data-model/issues/606#issuecommen
t-492277597
[40] https://github.com/w3c/vc-data-model/issues/606#issuecomment-492277597
<manu> [41]https://github.com/w3c/vc-data-model/issues/608
[41] https://github.com/w3c/vc-data-model/issues/608
manu: The reviewer in 4.3 is concerned about "type".
... I'm not sure what the requested change is.
<manu> [42]https://github.com/w3c/vc-data-model/issues/608
[42] https://github.com/w3c/vc-data-model/issues/608
<burn> Many thanks, Ted!
<manu> [43]https://github.com/w3c/vc-data-model/issues/609
[43] https://github.com/w3c/vc-data-model/issues/609
burn: Thanks, Ted for trying to handle many of the issues. I
like when you say, "Here's what I propose" and following with a
PR.
manu: This issue is re: conformance.
<manu> [44]https://github.com/w3c/vc-data-model/issues/621
[44] https://github.com/w3c/vc-data-model/issues/621
manu: Sercan, do you know about the issues raised by Oliver?
<Sercan_K> no I don't
Oliver: I can represent myself.
<manu>
[45]https://github.com/w3c/vc-data-model/issues/created_by/awoi
e
[45] https://github.com/w3c/vc-data-model/issues/created_by/awoie
<manu> [46]https://github.com/w3c/vc-data-model/issues/518
[46] https://github.com/w3c/vc-data-model/issues/518
manu: This about a credential with multiple subjects.
... We were going to add an example in a PR.
... Would this satisfy?
Oliver: That would be fine.
... I've raised another issue.
manu: Yes. In just a minute we'll address.
<manu>
[47]https://github.com/w3c/vc-data-model/issues/518#issuecommen
t-492280219
[47] https://github.com/w3c/vc-data-model/issues/518#issuecomment-492280219
<manu> [48]https://github.com/w3c/vc-data-model/issues/621
[48] https://github.com/w3c/vc-data-model/issues/621
manu: Re: 518, is adding an example with multiple credential
subjects sufficient?
Oliver: Yes.
... This is an issued because there is a problem with the
dynamic data types.
... In the case of json objects and the nature of json-ld array
types.
... It could be an array or a single object.
<manu> So, basically, this could happen -- credentialSubject:
{} ... or ... credentialSubject: [{}]
Oliver: The same data object could have two different json
representations.
<Justin_R> +1 to this discussion
<manu> credentialSubject: {}
Oliver: This could cause additional handling effort.
<manu> credentialSubject: [{}]
Oliver: That is correct.
<dlongley> `if(!Array.isArray(foo)) { foo = [foo]; }`
dlongley: This is not too difficult to implement. Varies by
language.
... The json parser is the heart of the issue.
... Once parsed, if normalizing is required, I don't think it
is too complex from there.
<Zakim> Justin_R, you wanted to discuss the implementation
impact of this
JustinR: I agree with Oliver.
... I want to add some experience from JWT.
... I think that it is not to hard for loosely typed languages.
... For strongly-type languages, I need a place to put this
object.
... It may be in a library that I have included.
<manu> +1 to Justin_R "everything converts to arrays
internally"...
<dlongley> +1
JustinR: The libraries I've seen, they parse the object into an
array even if it only a single value.
... The library on serialization has to decide to output a
single object or an array.
... This should be made clear in the text of the spec.
Oliver: I generally agreed with dlongley. There languages such
as java that makes this more difficult.
<Zakim> manu, you wanted to note that this happens w/ pure JSON
stuff as well where you can have more than one thing associated
w/ a property.
Oliver: In a code generation method, you need to specify types.
It is not easily done.
manu: ... This is a json issue. You need to specifically state
that multivalue items will be encoded as an array.
... Some developers don't like the complexity of single value
vs. single value in an array.
... Implementors have trouble consuming more simplistic
implementations.
... This may require libraries to clean up simplistic incoming
data from other implementors.
<Zakim> Justin_R, you wanted to describe a way forward
manu: Implementors should know that there will be variations in
input quality.
JustinR: Since the spec does not clearly in normative language,
we should state that there is a potential for multivalue
serializaitons to vary.
... Serialization controls whether a single value will be
output or an array with one object.
<manu> +1 to what Justin_R said.
<dlongley> +1
JustinR: We can warn in the implementation guide.
Oliver: Can we recommend that we avoid the compact form?
manu: I don't think it solves the problem.
... Can we add non-normative text as justinR suggested?
Oliver: Yes.
<manu>
[49]https://github.com/w3c/vc-data-model/issues/621#issuecommen
t-492286786
[49] https://github.com/w3c/vc-data-model/issues/621#issuecomment-492286786
manu: Ok, then we'll add non-normative text to the data
serialization section clarifying that implementers should note
that values associated with properties may either be single
values or arrays and suggest some mitigation strategies that
implementations can use.
<manu> [50]https://github.com/w3c/vc-data-model/issues/622
[50] https://github.com/w3c/vc-data-model/issues/622
manu: There will be a PR with that.
... Dmitriz, can we close?
Dmitriz: Yes.
manu: We have a solid path forward for all issues.
Implementation or other topics
burn: Any concerns?
jonathan_holt: Implementing is a challenge with QR codes.
... They are getting pretty dense.
... I've also tried JWTs.
<Zakim> manu, you wanted to note compression and CBOR-LD
mapping
manu: VC are not ideal for most use-cases are not ideal for QR
codes.
... Compression helps.
... CBOR seems to work well. many values compress to single
bytes.
... This is more efficient than JWTs.
DavidC: This is something that Drivers licenses could use
standardized representations of the CBOR.
manu: This could work, but it will take a large effort.
... There also remains to see what the method of transmittal
will be in the bulk of use-cases.
DavidC: Although we are not addressing protocol, I think it
will be a topic of great interest.
Oliver: Some variation on fields and approach will require us
to think about this.
DavidC: If we have DL that are not compatible with VC, it will
be a problem.
Dmitriz: The key material does not compress well.
burn: That is a group working on DL.
Dmitriz: Peer DIDs can affect this. QR codes might help
establish the channel, then turn to another representation for
the VC.
burn: Should we drop down to a shorter meeting or skip next
week's meeting?
... Focus on implementations would be best.
<TallTed> regrets for me for next week also, and possibly the
following (offline 5/18-28)
<manu> Luckily, brent, david, ken, and ted have been moving PRs
forward w/o me, which is awesome.
burn: Suggestions for productive work next week?
Oliver: We could talk about test suite?
dmitriz: Yes we could have a call about that.
<jonathan_holt> +1 to discuss test suite and json schema
document
<yancy> +1 to next week for test-suit and implementations
burn: Let's use next week to discuss the implementations and
test suite.
dmitriz: How long?
<oliver> +1 next week
burn: How much time do we need?
Oliver: 15-20 minutes.
<yancy> having audio issues
burn: Are there open issues?
<yancy> no specific time bounds in mind. would be nice to have
a call if issues come up in the near future.
dmitriz: Yes. Timeouts. Yancy's issue has a PR.
burn: Let's plan on one hour, and join one hour later.
<burn> We will begin the call one hour later than we did today,
and go for only one hour
burn: Focus on reducing issues.
Adjourn
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [51]scribe.perl version 1.154 ([52]CVS log)
$Date: 2019/05/20 04:33:09 $
[51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[52] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 20 May 2019 04:39:11 UTC