<manu> scribenick: ken
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.
<burn> 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> https://github.com/w3c/vc-data-model/pull/577
<manu> 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> 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> https://github.com/w3c/vc-data-model/pull/599
manu: Yes. please suggest the change.
<manu> 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> https://github.com/w3c/vc-data-model/pull/599
manu: Please raise a PR.
<manu> 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> https://github.com/w3c/vc-data-model/pull/619
<burn> Thx Ted, good suggestions
manu: DaveL mentioned the examples are wrong.
<manu> 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> https://github.com/w3c/vc-data-model/pull/624
manu: done.
<manu> https://github.com/w3c/vc-data-model/pull/625
<chaals> [+1 to having merged 623 now]
manu: Needs another review
<manu> https://github.com/w3c/vc-data-model/pull/626
<TallTed> manu - 614 ready to merge.
manu: Also needs another review
<manu> https://github.com/w3c/vc-data-model/pull/627
manu: Needs another review.
DavidC: It also resolves 586.
manu: Back to burn.
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> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+milestone%3ACR-Exit
<DavidC> not 626
I misheard you David
<manu> https://github.com/w3c/vc-data-model/issues?page=2&q=is%3Aopen+is%3Aissue+milestone%3ACR-Exit
<DavidC> no problem ken
burn: There are some new ones too
<manu> https://github.com/w3c/vc-data-model/issues/436
<manu> 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> https://github.com/w3c/vc-data-model/issues
<manu> 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> https://github.com/w3c/vc-data-model/issues/586
manu: Using JWTs with presentation.
DavidC: It has a PR
<manu> 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> 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> https://github.com/w3c/vc-data-model/issues/596#issuecomment-492273300
<manu> https://github.com/w3c/vc-data-model/issues/600
manu: Ted is correct, but DavidC is looking for the credential type.
<manu> 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> 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> 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> https://github.com/w3c/vc-data-model/issues/605
manu: None of these are CR issues. They are all post-CR.
<manu> 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> https://github.com/w3c/vc-data-model/issues/606#issuecomment-492277597
<manu> 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> https://github.com/w3c/vc-data-model/issues/608
<burn> Many thanks, Ted!
<manu> 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> 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> https://github.com/w3c/vc-data-model/issues/created_by/awoie
<manu> 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> https://github.com/w3c/vc-data-model/issues/518#issuecomment-492280219
<manu> 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> 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> 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.
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