<scribe> scribe: rhiaro

PR discussion

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

manu: we processed a number of PRs from last week, they've been put in, a couple of new ones to be aware of

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

manu: the first is 668, renaming iat to nbf. I wasn't on the call where the resolution happened, I probably would have objected because I believed it was a normative change, reading the w3c process very carefully, oliver has since let me know that it's more cmomplicated than it seems
... typically when you change spec text of normative statements during CR, if you clarify what it says that would change a previous implementation that was conforming to no longer be confomring, or vice versa, then you have made a substantative change and you need another CR. We are out of time, we can't have another CR therefore I said no we can't pull this in even though the spec is wrong
... Now it turns out that the test suite had the right test in there, and all implementations implemented it to the test suite not to what the spec says
... so if we were to pull this in it, no implementation would change, no regenerating test reports
... the question is does that trigger another CR or not. This is clearly a bug fix, but bug fixes can trigger another CR
... We are going to write to the process team and the folks at w3c that deal with process to ask them if our reading of it is correct. If it's correctw e'll pull in the PR. If it's not correct we'll not pull in the CR. We will probably issue an errata, and put text in to say hey this was wrong, to be clear, this is really messed up
... this is what some of the new language in the process causes working groups to do, it's wrong, nobody likes it, but because of the position we're in with the charter expiring, that's the position we're in. Depending on which way the w3c process team comes back we're gonna do one thing or another

<TallTed> rock and a hard place situation.

manu: That's where we are with that PR. I'll send an email to the process team

stonematt: want to clarify - we have content in the data model that says x and we have tests that test y and so they're out of sync?

manu: yep

stonematt: the question to the process team is which one should we choose to correct or leave as is and do errata later?

manu: yeah
... it's an unintended consequence of the way the new language in the process is written. We'll be raising it as a thing
... We're not that concerned because all the implementations are correct. This is purely a process discussion. We don't have implementations doing the wrong thing at least

<TallTed> Everyone who has standing to do so, should push W3M to generally have active groups proceed to conclusion by the rules that were in effect when they started, rather than changing rules mid-process. This is beyond frustrating.

jonathan_holt: is this nbt is not before time vs issued at time? it's semantics?

manu: some argue it's important semantics. You could argue that because we're only doing one and not both that the semantics don't matter. I dont' think anyone is really worried about what implementations are doing

jonathan_holt: the issued at timestamp, is there.. if someone implements it inappropriately is bad stuff going to happen?

manu: we can't think of a bad stuff. We've talkeda bout the attacks if it was implemented per the spec not per the test suite. There'd have to be business logic written in a verifier that specifically looks at iat and does something different than if it processed nbf. If that were to hold true then something bad might happen like a credential takes effect before a date that it should take effect. There's a lot of stuff that has to line up for

something even potentially to bad happen

TallTed: if you issue a large discount that's valid from jan 1 to mar 1 and it's issued in september then it can be acted on in october when it's not supposed to be

jonathan_holt: the worst case scenario like in health care, the physician gets their credential before jan 1 and the insurance comes back and says we're not going to pay you because you did the operation before you had license

manu: that presumes that the imlementation didn't check the test suite or failed that testa nd pushed the implementation into production
... it presumes you have a library that didn't test, read the spec and didn't read the errata, and didn't do any interop testing

<Justin_R> what's the point of the spec if you're supposed to ignore it?

manu: I don't want to spend too much time discussing it because from an implementation standpoint I don't think we're very concerned

<Justin_R> +1 to the suite testing the spec

jonathan_holt: I wouldn't take this to production, the test suite tests the spec not interop. I think it's safe because it's still a WIP we're trying to push out the door. Makes sense.

manu: we agree with Justin, w3c process is the issue
... this is a confluence of a number of different things
... a variety of factors
... we need feedback from w3m. Hopefully they'll make the right call and we can update the spec because it's a not a conformance change because implementations didn't change

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

<jonathan_holt> "this is fine": https://static01.nyt.com/images/2016/08/05/us/05onfire1_xp/05onfire1_xp-superJumbo-v2.jpg?quality=90&auto=webp

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

manu: PR 672. Last week Ted mentioned he'd like to see some credits. That triggered a number of other people to request the same. Some requests were reasonable and some that I have received have not been. Please stop emailing me to tell me to add you to the spec. We have to use data and history
... It should be a group decision ultimately. In order to attempt to make that decision I gathered some data
... there are 3 tools used to gather data. The data is supposed to track how people contributed to the spec. To be clear it's always dangerous when you do this and also need to involve to humans, can't just go by lines of code
... This spec was started in 2010, we have every single commit since then. We also have every issue and PR
... which includes comments on every issue, comments on PRs
... using that data to decide who is an editor, who is an author, who should be thanked in the acks. This always happens at the end of the spec. Almost always someone is mildly annoyed that they didn't show up. We're trying to balance

<manu> https://github.com/w3c/vc-data-model/graphs/contributors

manu: there's a tool called git-fame that tries to show you the level of contribution that people made relative to one another. It does thing slike ignores whitespace changes, tries to not count moving text from one area to another
... basically it attempts to make sure they are legitmate changes and not someone trying to game
... we have output from that. Then I wrote a tool over the weekend that crawls every single comment ever made to issues in the repo, every single PR comment, and then the amount of text that people wrote. We're not trying to count quantity over quality but we're trying to get an idea of how much people have written and that goes into a score
... the data is there and based on that and a bunch of discussion with a bunch of people with and without the chairs involved

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

manu: all of that has resulted in this PR
... tries to do some human judgement
... some people were not listed in data but were active in face to face or telecons
... not just looking at the stats, tries to bring in some of the softer things and so on

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

manu: We have shifted Dave Longley above Dan Burnett because the data showed Dave made more changes
... We have added Brent as one of the editors in the order of contribution
... there is text taht was added to the SotD section thanking certain individuals for going above and beyond, folks like matt stone, gregg kellogg, ted, oliver, dave lehn, adrian gropper
... people who have very heavily engaged in comments or by updating the contexts, making changes to supporting infrastructure to get the spec done
... we also thank rebooting the web of trust community and the people who facilite it and the internet identity workshop
... there's also a reference to dhs who funded some work on the spec
... in the acknowledgements section we thank every single person who raised an issue or contributed to a discussion either through a PR or th eissue tracker
... I'm certain we're missing someone, if you see that we're missing someone please bring it up and let us know where we should add them
... the most likely place is the acknowledgements
... any questions or concerns about the process?

<Zakim> jonathan_holt, you wanted to ask what the semantic diff is between and to

jonathan_holt: it would be interesting to eat our own dogfood and have a credential to prove you were involved

<Justin_R> +1 to dogfood

<stonematt> +1

manu: if you'd like to write that it would be awesome. I agree

jonathan_holt: sure
... an aside, interesting nuance, that would be a perfect application, especially the zkp, it's not necessary that I need to be acknowledged but for prosterity to have proof I was involved

manu: it would be a good thing to do, someone would need to pick that up

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

manu: next pr is 674
... this is a discussion that david ted and brent have been having, around whether types are explicitly or implicitly required
... we pulled in brent's PR and davidC wanted some more additions made to further clarify how the language around type
... there's a PR and an active discussion, DavidC wrote some text, I took it and tried to align it with the spec being careful not to make new normative changes and there are disagreements about whether or not we should be able to make normative substantive comments. Anyway there's a discussion, DavidC would like to see it run its course and for us to put that content in the spec
... others are concerned that it may be too much and may further confuse that section
... please engage in that
... so we can come to some agreement on that PR

stonematt: we're in a bit of a holding pattern while the discussion matures, we all knwo where we are in terms of timing, we need to not let it steep for too long. What do we expect to have a plan of action by next week on this? Do you think you're close enough that there'll be a resolution by next tuesday to vote on?

manu: I think there's a fundamental philosophical disagreement and I believe DavidC's position is the group is flipflopping on what it said. David says the group always meant explicit and not implicity and he'd like to further clarify that and other folks are disagreeing that we meant explicit in the way that David is asserting
... I don't see an end to the discussion. I think the thing that is going to force the pull request is the call to go into proposed req. If we can't close this discussion the text will not make it into the spec and it'll go out as is. The spec will be mildly confusing
... the problem with the types section is we've had 4 different people write text for it and there have been normative statements and there are ways to read some of them that aren't clear. Everyoen is saying the text is clear except for David who is saying it isn't
... The type section si way more complicated than it neesd to be. In hindsight we should have pushed back on all of the prescriptive things people wanted to do and put all of the prescriptive stuff in an implementation guide. Right now it's a mess. Because of that we're having this dicsussion

TallTed: I want to ask that anyone who has an actual opinion on this add it to that thread
... I'm pretty sure that most of us are in rough agreement, at least that's how I'm taking the silence. I'd like to know if I'm wrong
... I think David is taking the silence as agreeing with him
... would be good to know where people are standing

stonematt: this was a pretty animated discussion a couple of weeks ago, a week following the resolution and david started his objection that resulted in this PR. We had a bit of a discussion offline with the chairs and editors to try to get to a point where we thought we could agree and if we're coming to an impasse I think getting a few more voices into this topic would be helpful
... doesn't have to be a long contribution, but indicate wher eyou are

<scribe> scribenick: dmitriz

Issues

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

stonematt: our issues list has shrunk a bit, a number waiting on the '7 days close' to pass

<manu> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Adefer

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

manu: 537 is a request to update to the JSONLD 1.1 spec. Everyone agreed, but now it's being used to force to go to another CR
... which is not true, since none of the implementations changed
... I still need to update that reference asap, tho.

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

manu: we have the three Tracking Issues, that are tracking duplicate issues

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

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

manu: those are going to stay open until we go to PR

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

manu: 653 - I hesitate to close it until the Type discussion with David is resolved
... I'm deferring to the chairs on how we want to handle it

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

manu: 667 - iat to nbf change. Waiting for feedback from the W3C Process / mgmt folks

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

manu: 675 - updating editors and authors. We have a PR for it, we have multiple positive reviews, but we'll wait a couple more days
... those are all the remaining issues!
... which means we should probably go to PR as soon as we get a full top-to-bottom read from a few people in the group
... we'll request that Grant Noble make one more pass through the spec. I will do that also
... anybody on the call, please make another pass-through on the spec
... Then I need to remove all the 'Issue at Risk' markers
... every feature marked at risk now has multiple implementations in the test suite.
... dissenters please speak up.
... next week, the group should have a call for consensus to move the spec to PR
... questions/concerns?

stonematt: nice job everyone, getting us to this point!
... we can almost see the end of the tunnel! :)

Test Suite issues and discussion

<stonematt> https://github.com/w3c/vc-test-suite

<bigbluehat> scribenick: bigbluehat

<dmitriz> results at: https://w3c.github.io/vc-test-suite/

dmitriz: matt dropped the link to the issue. this is the link to the implementation report

<dmitriz> https://w3c.github.io/vc-test-suite/implementations/

dmitriz: a couple of changes to the test suite report for clarity and ease of use
... we've broken out all of the sections into their own tables
... a couple new implementations are joining us
... and the other feature is that implementations can mark each of these features as "not supported"

<stonematt> Brightlink will submit in implementation report this week

dmitriz: for example if you look at ZKP's, there are some that state they don't support it
... sounds like Brightlink will send in their report this week
... I'd encourage everyone to rerun these tests, and submit another report

stonematt: because?

dmitriz: there's a little bit of confusion on the JWT tests
... there was a test updated between reports
... so I'd like to get fresher reports

<TallTed> every sub-section header has the same frag-id ... they all go to https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results instead of going directly to, e.g., `Refresh Service (optional)`

dmitriz: and give folks to explicitly state when they don't support a feature--vs. errors

<TallTed> +1 manu

manu: a minor nit. in the table of contents we say "informing testing results" but there are no section pointers
... could we link to those?

dmitriz: of course
... on the repo itself, we don't have any pending PRs

<dmitriz> https://github.com/w3c/vc-test-suite/issues

dmitriz: on to issues
... we have a documentation issue which has a PR
... which I recommend we close, but I want to give brent a chance to see if that's still unclear

<stonematt> https://github.com/w3c/vc-test-suite/issues/14

dmitriz: number #14

<dmitriz> https://github.com/w3c/vc-test-suite/issues/14

dmitriz: we basically asked for configuration example and instructions

<dmitriz> now added at https://github.com/w3c/vc-test-suite#configuring-the-test-suite

dmitriz: which has now been added

<TallTed> is there anything about "support asserted but untested"? or is that implied by "untested" vs "not supported"?

dmitriz: general instructions in addition to JWT specific ones
... the remaining issues have to do with the context hosted at W3C
... not sure if kaz is on the call today
... or if we need more steps to take on that one

stonematt: kaz? are you here today?
... guess not

dmitriz: so we'll wait on the content-type change for the W3C to fix
... if anyone runs into a problem with this, please let me know or raise an issue
... we can walk you through the recommended embedded context procedure for your library
... any questions or comments?

manu: do you expect any changes or modifications to the test suite at this point?

dmitriz: I feel pretty confident at this point
... but I am going back through the spec to see if any required text changed status
... because of recent PRs
... but I feel this is already pretty stable

stonematt: any PRs you know of manu that change anything?

manu: no, we've made no substantive changes

<Zakim> manu, you wanted to request that we do <section><h2> for test groups.... and to

manu: some of the language changed, but not the conformance criteria

<manu> +1, yes, thank you dmitriz !!!!

ken: just wanted to thank dmitriz for this great work on the tests

<Justin_R> +1

ken: it's much easier to read

TallTed: similar to what ken just said. this is a big help
... I had one question about "no support" vs. "untested"
... does "untested" mean asserted support, but untested?

dmitriz: "untested" just means changes in the test itself, and please rerun your tests for your implementation

TallTed: yeah. I'm mostly wondering about the first three JWT tests

dmitriz: this was probably because the tests were renamed

mirceanis: I can confirm that.

TallTed: thanks

<brent> evernym will re-run today

<manu> 8 implementations with two more on the way is *great*

<dlongley> +1

stonematt: that prompted me to go look for what the outcome indicators mean...but there isn't one

dmitriz: ah. right. I can define those

<brent> +1 to a legend

dmitriz: excellent point
... I'll read up on a11y stuff

stonematt: can bigbluehat help with that?

bigbluehat: sure. it shouldn't be too hard. happy to take a look

<dmitriz> scribenick: dmitriz

<Justin_R> Test status: 🤷‍♀️

<bigbluehat> stonematt: implementation time. this is a bit of an open floor time

General implementation issues?

Implementation Guide

<stonematt> https://github.com/w3c/vc-imp-guide

<Justin_R> --- me? Or is there another justin?

<Justin_R> Ok! I didn't remember signing up for that

<deiu> https://github.com/w3c/vc-imp-guide/pulls

andrei: let's take a look at the PRs, 2 outstanding

<deiu> https://github.com/w3c/vc-imp-guide/pull/13

deiu: PR 13 is a minor editorial one, suggest we merge it
... any objections?

brent: I can take care of the merge conflicts

<deiu> https://github.com/w3c/vc-imp-guide/pull/7

deiu: let's take a look at PR 7 while we're waiting
... this is about adding sections on Identifiers and Proofs
... thank you Ted for all the suggestions
... Everybody else, take a look at the PR
... +1 if you feel it's in a good shape.

TallTed: seems legit.

stonematt: do you have the permissions fix from last week?

deiu: yes
... unless anyone objects, I can click the merge button.

<manu> +1 to merge... weird whitespace issues, but meh.

deiu: ok, merging.
... manu - we can fix the whitespace in the next pr

that leaves us with just one PR from Brent, still a work in progress

<deiu> https://github.com/w3c/vc-imp-guide/issues

deiu: brent, ping me when you're done.
... moving on to the Issues
... in chrono order

<deiu> https://github.com/w3c/vc-imp-guide/issues/1

Adding standard JSON Schema for implementors. jonathan_holt has been volunteered

jonathan_holt: I have a WIP schema right now, I can post it, we can start the conversation

deiu: great

<deiu> https://github.com/w3c/vc-imp-guide/issues/2

deiu: #2, Guidance to prevent unauthorized reuse by verifiers. - dlongley?

dlongley: haven't had time for PRs

<deiu> https://github.com/w3c/vc-imp-guide/issues/3

deiu: #3, Determine how/if WebAuthn will work with VCs
... we closed the corresponding issue in the VC spec, moved it to here (impl guide)

<deiu> https://github.com/w3c/vc-imp-guide/issues/4

deiu: #4, Reference or attach credentials in another credential - ganesh?

manu: ganesh is on vacation, don't expect anything for 2 weeks. THis is going to be a Note anyways, we can publish it like 2 weeks before the WG shuts down
... we have a month and a half

<deiu> https://github.com/w3c/vc-imp-guide/issues/6

deiu: #6, Suggestions on progressive trust
... brent?

brent: that's the WIP PR that's still pending

<deiu> https://github.com/w3c/vc-imp-guide/issues/8

kaz: dezell, welcome

dezell: this is David Ezell, having connection trouble

<deiu> https://github.com/w3c/vc-imp-guide/issues/8

deiu: #8, benefits of different syntaxes
... partially covered by PR #3 that just closed. It still needs a section on JWTs
... (we'll add that in a separate PR).

<deiu> https://github.com/w3c/vc-imp-guide/issues/16

deiu: ok, last issue, #16, adding a section on how to author a new VC - dlongley?

dlongley: yep, will get to it asap.

<jonathan_holt> see: https://github.com/w3c/vc-imp-guide/pull/17

deiu: this concludes our issue list

jonathan_holt: just posted a PR for the JSON Schema

deiu: do you mind if I add a WIP label to it? is it ready for review?
... ok, adding.

stonematt: if anybody has opinions on JSON Schemas, please add feedback

<stonematt> DavidC are you on voice today?

stonematt: manu - any parting comments?

<Zakim> jonathan_holt, you wanted to ask process question in w3c

<inserted> kaz: As the W3C Process Document states, the requirements for wide reviews are not precisely defined.

<tzviya> https://github.com/w3c/w3process/issues

<tzviya> https://www.w3.org/community/pwe/

<stonematt> time check.

<Zakim> manu, you wanted to discuss next steps.

stonematt: ok, we've gone to our agenda for the day
... open floor for any other topics/issues.
... ok, I think that's it