<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> 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.

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> 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.

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