<scribe> scribenick: bigbluehat

Agenda review, Introductions, Re-introductions (5 min)

stonematt: any questions about the agenda for today?
... introductions and reintroductions time
... anyone new here or anyone who would like to reintroduce themselves?

Introductions

stonematt: no one new. how about a reintroduction?

Unassigned issues [1] (5 min)

<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+no%3Aassignee

stonematt: the only unassigned issues here that are not deferred is this mime type guidance
... we've talked about it in past calls
... it's a few weeks old. not a CR blocker
... can I get a volunteer, though?

brent: I volunteered last time. not sure why my name's not on it

stonematt: sorry about that. I tried to assign it, but it didn't work
... if anyone can help me sort that out, I'd appreciate it

manu: it typically means that brent isn't assigned to the W3C group
... brent have you associated your github account with your w3c account yet?

brent: yeah. I thought I did

stonematt: k. we don't have to solve it on the call today
... I mentioned brent in the comment thread. maybe you can track it from there
... in any case, I think we have it in principle
... next item on the agenda is presentation to TAG

Volunteer to Present to TAG (10 min)

stonematt: a few items came out of an early discussion about this
... things we might do to help move the TAG review forward quickly
... someone suggested finding a volunteer to present our work at a future TAG meeting
... so we're working on getting the date of their next meeting
... and looking for a volunteer to go there and present this work to them
... given the scope of the data model, we think the TAG review is relatively lightweight

DavidC: just wanted to ask where the meeting is?

stonematt: I don't think we need to be there in person

<dmitriz> I'd like to volunteer, to call in as well

burn: in the issue, I have made the comment that we'd like to come and present
... but we need to wait and see if they wan to do that
... and if they suggest a call time

manu: I'm happy to be there in a support capacity

<Zakim> manu, you wanted to support w/ TAG discussion.

manu: I can be there to help navigate questions that will come up
... but I would prefer to have someone else take point

brent: I'd be happy to take point
... since I ultimately edited the explainer, I'd be happy to represent that
... and it would be very helpful to know manu will be there to help navigate

stonematt: any general pointers to these volunteers?

manu: keep it high level and focused on Web architecture generally
... you'll get questions around privacy, architecture, but fundamentally if you stick to the explainer
... keeping it high level, we can still be ready for any tricky questions that they may ask
... also checkout the design principles page (tnx tzviya!) https://w3ctag.github.io/design-principles/
... they will want us to understand those and talk with them in mind

stonematt: the next item that came out of our discussion with Phillip, was implementation status

<stonematt> https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0

<manu> Also note that many of those design principles are specific to browsers.... so they don't apply to this work.

Implementor - Producer/Consumer (10 min)

https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0

stonematt: partly this is about understanding implementation capacity
... are these implementations planning to consumer or produce or both?
... consequently, we changed the nature of the report to match those columns--and we'll add a "both" column also
... If you've filled this out already as an implementer, please go back and clarify which you are: producer, consumer, or both

burn: having one producer and one consumer for each feature is our ideal story
... at least one of each for each feature

stonematt: I'll go through the list and update the counts
... any questions about this while we're here?

manu: so. consuming is untestable
... we made the point to focus on data model, such that the "consumer" here *is* the test suite
... we're only testing document conformance
... and not consumption per se

burn: he understands we're not testing those things
... we're really just looking for the claim that they are producing and consuming

manu: got it. testing that both sides of the ecosystem will (in theory) produce conforming documents that could work together

kaz: the basic idea of this procedure for CR transition
... is based in part on HTML testing
... the server provides HTML docuemnts via HTTP to the browser, and it's rendered based on the DOM structure of the document
... the basic assumption is that somebody or some software will process that data somehow
... if the test suite is kind of a consumer, maybe we can count it as a consumer (implementation)

stonematt: should this idea change how we track stuff in this sheet?

manu: if we count the test suite as one, we simply start counting at 1 not 0.
... it's useful to tell folks this library in the test suite will do is test the validity
... so we can't say anything about verification, etc.
... and we can't do that without heavily changing the test suite design at this point
... I wonder if we should focus this on a data gathering effort--it's great to know who's producing and consuming
... but then our tests can still focus on the data documents validity
... we can use that base line validity + information about the ecosystem to still present a clear picture of what we're doing here together

stonematt: it might also work to help make the case for a charter extension

manu: yes. that could be beneficial

dmitriz: there's a PR on the test suite that expands it and fills out some of the remaining stubs
... it'd be great to have someone review that soon

<Zakim> manu, you wanted to note that that's probably my job (but would appreciate help)

manu: that should probably be me, but I'd also appreciate bigbluehat's review on that

<kaz> https://w3c.github.io/wot-thing-description/testing/report.html fyi wot td report

kaz: this is mostly just FYI, but the Web of Things WG is publishing something similar
... their implementations are also kind of classified as consumers and producers
... their mechanism (device side vs application side) is simple and easy to understand
... the device side generates a JSON-LD data model named WoT Thing Description
... and the application side uses that data model to control the device.
... so that sort of combination (somebody generates a document and another uses that document) would help explain the interoperability of the data model
... section 6 shows their list of implementations and section 8 shows the concrete feature coverage

stonematt: is this inline with what you were thinking, manu?

manu: no...because we focused the test suite on the data model
... and now this conversation is heading this back toward consumer/producer testing

burn: I do not agree that's not what's happening here

manu: sure. maybe we can take this offline
... we can leave things as is, and get dmitriz's work in, etc.
... or we can rip it out and wrap it in something else to try and test verifying, etc.
... I don't think we need to change anything to get through REC
... but if people want to say I am a conformant implementer, then we have to change the suite

TallTed: we can't do that.
... we don't have time, and as soon as we get into the actual implementation--and beyond the data model
... we're just testing that a document can be written that matches this model
... if we can't test this with human eyes, then we've screwed it up
... I understand some amount of automation is helpful
... but there's nothing that says how to do really either side of those

<Zakim> manu, you wanted to note "yes, not a full blown 'verifier'"

manu: partial agreement with TallTed
... yes, we agreed to focus solely on data model
... so we can't go all the way to building a full-blown verifier
... you did say one small fragment there TallTed about "doing something" with the document
... and not fall over
... can you do something with the data model document and not fail in some way

TallTed: if you're going to generate a document that is verifiable, then it has to have these pieces of data in it
... if you're going to do something with that document, then it must have these pieces in it

manu: we have tests that show they can consume the data model
... that's what the test suite currently does
... we also have a foundation that others can plug stuff into that folks can test that the test suite is consuming stuff from their implementations

ken: do we need to draw a line between each of the field elements?
... do we not allow the actual verification to occur?

<oliver> +1

burn: I'm about to call chair prerogative on this to stop the discussion.
... we do not need to do any execution on this
... manu you mentioned that you wanted to show that folks do process these in some way
... and our conversation with Philip included that it would be nice to promote that people say they can consume and produce
... but I don't see why the test suite needs to test or prove any of those statements
... just the document validity--per our charter
... this is not a new realm; nothing's changed.

kaz: if we should stop the discussion here, I'm OK to stop here, but I just wanted to mention that saying "generator" here might be causing the confusion
... for the Web of Things work, the generator implementations don't really "generate" the Thing Description, but the people manually generate those docus
... and then attach that information to the devices
... and then that device exposes it to consumer applications
... it's the combination of server/client and device/application

<Zakim> manu, you wanted to note "if you can generate, and it's valid, the assumption is you can consume... because it's valid"

kaz: if there's a way to provide data producer and consumer, that may simply prove that the data is portable

manu: thank you for all that input. it was very helpful
... Web of Things is actually doing something similar--just focusing on the consumption not the processing of the documents
... if the test suite is testing validity, and you can't give it a valid document, then you're not generating valid documents
... but if you are, then our test suite consumer will validate that for you
... any consumer should do the exact same things that the test suite is doing
... no need to change the test suite; we're just going to point out lots of people are doing things with these credentials

oliver: the same question as ken earlier?
... should we implement the proof stuff in the test suite?

<Zakim> manu, you wanted to note we should implement optional stuff in the test suite.

manu: that stuff is marked as optional in the test suite
... it's not something that you need right now
... but the last thing we want is for someone to go do JWT stuff in a different way than what' sin the spec
... so providing guidance is important here and now
... we're tap dancing around our charter, because we still want an interoperable ecosystem
... but the test suite can only formally test the data model

oliver: so we can add these things?

manu: yes. the test suite itself will test the validity of the signature, etc. but your code will generate the signature

stonematt: thank you everyone for working through that
... what I heard was the test suite won't change
... and the list of producer/consumer is helpful but does not effect how we test

F2F Tentative Agenda (5 min)

stonematt: sorry I don't have the tentative agenda done yet
... but I hope to get it out this week, so we can review it next call
... we did go through the last list of brain stormed questions
... and we've got a high-to-low priority list
... we have a full 2 days planned
... so watch your email for more information

PR review (CR Blocker Checkin) (15 min)

<stonematt> https://github.com/w3c/vc-data-model/pulls

stonematt: manu, could you run us through these open PRs?

<manu> https://github.com/w3c/vc-data-model/pull/384

manu: the group decided to move this content to an appendix, so that's moving down
... there are a number of issues raised on the PR, and I've updated the PR as a result
... the new text is available via:

<manu> https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/384.html#proof-format-trade-offs

<manu> https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/384.html#pf1

manu: if you go below that section there are explanations for ever single trade off
... still need to check grammar, etc.
... and I still need folks to provide further review
... guessing 2 more weeks of discussion before this goes into the spec
... any more questions on this one?
... before we move to "subject only" PR, all these others are looking good

<manu> https://github.com/w3c/vc-data-model/pull/412

manu: and I don't think they need discussion today
... 412 is the "subject only" use case
... after going back and forth with DavidC a bit, it seems DavidC's preference is to leave the spec as is
... the reasoning behind the PR was that no implementers have said they plan to do subject only as expressed
... the current text currently frames "subject only" via the terms of use feature
... and there's stuff in the test suite to test it
... the approach in the PR is more complex
... but that's because it's more full featured, etc.
... the options seem to be:
... 1. we keep it as is, mark it "at risk"
... 2. we ask implementers to state their preference
... if they are interest in subject only and state which they prefer--that would be helpful
... 3. would be to ask implementers to pick one or the other--and if we have none, we remove the feature altogether
... DavidC had an alternative suggestion
... as implementers to pick one now
... and if they don't pick any, we leave the spec as is and see what happens with it later
... my concern is that it's too much for the group to make a decision on today

stonematt: can you sum up the choices at hand?

manu: the choice is a chairs call to make
... the one in the spec does not have any implementers interested in implementing it
... the one in the PR changes it to use the termsOfUse field, and if it's done that way, then Digital Bazaar would implement it
... but we'd need at least one other implementer to pick one way or the other
... so, the chairs call comes in with the "do we strike the change?" or leave it alone

DavidC: my proposal was actually to focus on the choices of the implementers
... if they don't pick it, then we leave it alone
... and it gets taken out if no one implements it at the end of the CR process

stonematt: is termsOfUse also at risk?

manu: no, just subject only
... there's a simpler test to see if you've removed termsOfUs entirely
... what we may want to do is discuss this on a call
... implementers may not be aware of the difference at this point
... we could either take telecon time
... or we could get more folks to review the PR
... but right now we don't have enough eyes on this

burn: if I understood this correctly, at some point there will be a doc we call CR
... there will be no features that have no implementations or too few implementations
... I'm not keen to leave something in the spec...speculatively
... that seems like a decision to be made as early as possible

<DavidC> Manu +1

burn: the spec should be the best we have at the moment of publication

<DavidC> Not 2 ways in the spec. Either 1 way that we know will be implemented, or leave as is

oliver: this may be off topic, but haven't we discussed whether we want to have comparison use case specifically?
... I wasn't able to find it in the minutes, that things should be more use case specific, right?

DavidC: both manu and I want one way in the spec
... whatever the implementers choose

<Zakim> manu, you wanted to say no, not two into the spec, one that we know will be implemented.

DavidC: if they don't choose, we leave what's there in place and see what happens

manu: +1 to what DavidC said for clarifying the plans
... as an editor, though, I'm not keen to leave features in the spec which has no support
... vs. taking an opportunity to say something about an approach that does have an implementation
... so, DavidC it's probably up to you to drum up the support for the subject only as described now in the spec
... with my Digital Bazaar hat on, we believe implementing the current approach isn't worth the time as it doesn't properly solve the use case described

<ken> +1 to subject only is a part of TOU

burn: if I understand this, manu sees this as solvable via termsOfUse
... but if it's not done that way, and left as is, then we'd loose the feature entirely

TallTed: given that there are 2 paths to go down
... this is a thing reasonably put in an appendix
... I'd suggest the current status quo be inverted
... the thing at risk should be put in the spec
... and the current "subject only" should go into the appendix

burn: there are ways we could handle this
... we could change it in a later version

TallTed: my concern is mostly blocking other alternatives by leaving the feature to fall on the floor

stonematt: we'll have to do this again. Maybe on the next call
... thanks everyone! see you next week

<kaz> [adjourned]