<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> https://github.com/w3c/vc-data-model/pulls

manu: we have a number of PRs, gonna start at the bottom with 641

<burn> 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> https://github.com/w3c/vc-data-model/issues/518

<manu> https://github.com/w3c/vc-data-model/issues?page=1&q=is%3Aissue+is%3Aopen

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> 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> 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> 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> 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> 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> 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? 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> https://github.com/w3c/vc-data-model/issues/632

<manu> https://github.com/w3c/vc-data-model/issues/633

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