<scribe> scribe: nage

Agenda review, Introductions, Re-introductions

stonematt: we will do a quick action item review, unassigned issues, then progress on TPAC sessions from last week, then the rest of the data on data model PR review and if there are any test suite updates
... any objections?
... is there anyone new on the call today that would like to introduce themselves?

manu: an addition to the agenda is an update on the test suite

stonematt: we will make time for it today
Action item review

stonematt: two action items from last weeks minutes, issue 227? manu?

manu: there have been a bunch of reviews of a lot of things, but not 227

Assign owners to unassigned issues

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

stonematt: next up, open issues. And there are quite a few here today.
... should terms like AgeOver be in the context? Open by Chris?
... we are not really looking for discussion, but to have someone raise their hand to own the issue and drive the discussion to eventual closure
... Chris is this a topic that you can shepherd through the process?

cwebber2: since I am already bumping into the things that are missing, I can commit the things that are missing in a branch as I work on the test suite. How do people feel about that?

[ affirmative sounds on call ]

stonematt: next is privacy issue 244

manu: A heads up, I took a number of editorial issues, so I have grabbed those

stonematt: I think this privacy issue might be one for DavidC to drive. Anyone else raising their hand to take this on?

manu: I will take 239 for identifier registries

stonematt: how about 240 (inconsistency in presentation)

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

stonematt: there is a long response from JoeAndrieu here

JoeAndrieu: I made it worse
... David's suggestion is a couple of words, but this uncovers a deeper issue with definitions in several places
... adjusting definitions may be difficult at this point

stonematt: Joe can you drive this discussion to make the right kind of progress?

JoeAndrieu: yes. I'd like input from the chairs and manu.
... please read the comments there

burn: I'm looking for the TL;DR and don't see it

JoeAndrieu: "too long must read please" will have to do

stonematt: I will touch base on this next week, does it need that kind of urgency?

JoeAndrieu: I think we can do a quick PR for what David raised. We need to decide if there is another issue to add, or just let it go.

stonematt: so short term go David's route and then add a new issue on the broader topic in the comment?

JoeAndrieu: that is right

stonematt: I have recorded that in the issue itself
... thank you everyone for closing out the unassigned issue list.

<Zakim> manu, you wanted to add to agenda

manu: that was from before

Confirm progress on TPAC sessions

stonematt: a couple things we want to do today...

<stonematt> https://docs.google.com/spreadsheets/d/1aYodpYXQg_C9zn3HcNQoMN2A_ESsArJaA4jl3x0cahE/edit#gid=975531401

stonematt: this is our planning sheet for the last few weeks for the agenda
... there are names with question marks here
... test suite discussion, cwebber2 are you available to lead that discussion?
... and the chairs need to confirm with ChristopherA about his topic
... we will confirm that out of band

cwebber2: I will not be at TPAC, but I could try to dial in for this
... will remote dial in be possible?

burn: we will try to do that, but it isn't completely clear if will be available or what the quality will be

cwebber2: I will do what I can, prepare, and appoint manu to prepare to be me if needed

manu: someone will be ready to pick it up if cwebber2 cannot
... Ganesh or dlongley

stonematt: any other comments or orders of business for the agenda itself?

kaz: relative to the remote connection, we can probably provide a webex connection
... there should be a speakerphone at the venue

stonematt: we are also hoping Claire can dial in for the threat model discussion, that access will be used by our community
... the second order of business on the TPAC topic is the slide deck
... we have created a master deck, like we did last year. One deck per day for each day-long session
... this way we can run through it in order and publish the experience

<stonematt> https://docs.google.com/presentation/d/1uYpGnciqzR3g0cfrWRrhCoHhqV8VyBxPclqz3co3Oq4/edit#slide=id.p

stonematt: the link for that deck is here
... this should be edit-able
... for each session there is a title slide that introduces the session and time slot
... depending on your preference you can place slides directly into the deck (recommended) or alternatively reference another deck you use for another purpose
... and add a link here to be able to open that deck -- the link should be publicly available so everyone can navigate to the material being shared

<Zakim> manu, you wanted to specificaly point out d1s2

<manu> Looking at TPAC Agenda -- https://docs.google.com/spreadsheets/d/1aYodpYXQg_C9zn3HcNQoMN2A_ESsArJaA4jl3x0cahE/edit#gid=975531401

manu: jumping back to a more specific agenda item (here is the link), B1S2, line 6 -- the joint session. We will need a 15 minute update on the state of the spec for the Web Commerce group
... the other heads up, any CCG chairs will need to give an update on DIDs from the CCG perspective needed
... I will be doing something on webauthn and DIDs

<stonematt> ACTION: chairs to present in the WCIG on the current status of VC

manu: there is one more that I am forgetting right now
... I have a feeling you will be generating them for other reasons, but we need rough drafts by next Monday

JoeAndrieu: 5 slides about DIDs by Monday?

manu: yes

<stonematt> ACTION: JoeA to make 5 slides about DIDs by Monday for WCIG at TPAC

manu: the other thing, that session has been extended by 15 minutes, noted in the TPAC agenda, which will also cover digital offers, which is a commerce group use case
... they asked for that 15 minute extension

stonematt: I will take an action item to update and tweak the time slots that need to be corrected with respect to the WCIG

<stonematt> ACTION: chairs to tweak TPAC schedule to reflect extra 15min for WCIG

nage: we can help with the slides, but JoeAndrieu is the lead on that

JoeAndrieu: yes, I can reach out for what content other have

<manu> +1 to what tzviya just said.

tzviya: we would like to know about whatever resources are available to the public

stonematt: should they email you those resources?

tzviya: yes, that would be helpful

stonematt: On the master slide deck, we will review that again next week

<Identitywoman> I have quite a few slide decks up about DIDs and Verifiable Credentials - https://www.slideshare.net/kaliya

stonematt: discussion leads we expect to see some movement here next week

<Identitywoman> If people want/need actual slides I am happy to share (they are in keynote)

burn: for those of you working on decks outside of this one. Please migrate your content into this deck. It is helpful because we can snapshot it before and after the meeting as a pdf as a record of what we did and discussed,
... if there are pointers to external docs it isn't as good as getting it into this deck

stonematt: any objections to moving to the next topic?

Data Model PR review

stonematt: Now to the data model PR review

<stonematt> https://docs.google.com/spreadsheets/d/1aYodpYXQg_C9zn3HcNQoMN2A_ESsArJaA4jl3x0cahE/edit#gid=975531401

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

stonematt: this is the link to the list
... manu, would you mind kicking off 246 and any other issues you have insight about?

<dlongley> https://github.com/w3c/vc-data-model/pull/246

manu: 246 is the result of input from Daniel Hardman, tzviya and others in the accessibility community
... it is also linked to tzviya's PR
... it creates an accessibility considerations section equivalent to privacy and security sections
... it says to take a "data first" approach
... to make it so interfaces can customize themselves for accessibility
... I don't think that PR is contraversial
... once that is pulled in I suggest we pull tzviya's PR in as well as an introduction to talk about that
... 246 and 238
... I believe that by pulling those in we address the things Daniel Hardman is trying to say with 235

<kaz> https://github.com/w3c/vc-data-model/pull/238

<kaz> https://github.com/w3c/vc-data-model/pull/235

manu: I will pull those in by the next call unless we see objections in the PR
... I think the next one is cwebber2 the consistently used type issue

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

cwebber2: I have updated this after our last call with one of two paths forward
... with VerifiableCredential -> Credential and then a type for Proof
... the other is all use of Credential->VerifiableCredential and then not use Credential directly
... it would be good if DavidC could represent what he wrote

stonematt: unfortunately he isn't on the call today

cwebber2: then I don't think we have resolution on the PR yet. I would be very interested in more feedback on this

<Zakim> manu, you wanted to also disagree with cwebber2 -- but only because WebAuthn and other security community folks may not like it.

manu: So I want to push back against the credential thing, only because other communities might be upset if we name everything a credential
... the change to Verifiable Claims is evidence that there is controversy there
... my suggestion is we use VerifiableCredential everywhere but it is not valid if there is no proof
... from a purely logical standpoint this isn't the ideal, but may lead to less conflict

JoeAndrieu: So, I have feedback, but first a quick question, no proof means it isn't signed in any way?

manu: correct

JoeAndrieu: so grabbing the whole term Credential might be too much

<cwebber2> what are examples of those JoeAndrieu ?

JoeAndrieu: having VerifiableCredentals in that format without proofs is important for a standard, even if they cannot attach proof

<cwebber2> bearer credentials?

<Zakim> manu, you wanted to ask Joe a question

manu: I believe what you're saying is that there may be other mechanisms to verify the credential beyond an embedded proof. For example if you've already authenticated through a different mechanism?

<cwebber2> that's fine but that doesn't sound like it's "verifiable", though i can understand why we might still use the term because of politics

JoeAndrieu: If you have some data you want to ingest that doesn't need proof, it would be convenient to use the data model without the proof without having to support multiple formats or vocabulary

<manu> Yes, good point, Joe A.

JoeAndrieu: my point is they should be VerifiableCredentials (meaning of that type using that format) but not cryptographically verifiable using the information contained within them

burn: I agree that this is logical and cryptographic information could come from somewhere else (like what manu said)

cwebber2: A) we want to use the term VerifiableCredentials
... B) the "verifiable-ness" usually comes from the proof, it could come from elsewhere, but that isn't relevant in the sense that the data format is the same whether the proof is provided or not
... I think I can believe all of that, and if we acknowledge JoeAndrieu's comment it sounds like we should probably drop "Credential" from our vocabulary alltogether
... effectively we still want to use that term to show that our machinery works

JoeAndrieu: I think the type should always be VerifiableCredential and not Credential, but here the term could remain in the sense that "the Credential contains Claims"

cwebber2: So how do people feel about dropping the generic term credential from the spec?

<cwebber2> I don't understand why we'd both say "VerifiableCredential is still what we want to call things even if it's not be verifiable as our schema"

<cwebber2> AND say

<cwebber2> "keep Credential though"

<nage> -1, I don't like letting the term go so easily, but I agree with the restructure of the data model spec -- just wish we could keep using the generic term as it may be important to protocol discussion to come

<manu> +1 to nage

JoeAndrieu: Credentials contain claims which are assertions of fact, but we don't verify the correctness of the assertion, just its existence

<burn> +1 to nage

JoeAndrieu: they are assertions of statements of facts from the issuer, and talking about credentials independent of the verifiers is important

<JoeAndrieu> (sorry nage)

manu: I would like to raise something slightly different, saying I don't think we should let the term go

<Zakim> manu, you wanted to maybe object

manu: fundamentally a verifiable credential must be verifiable in some way or it isn't technically verifiable
... I don't think it hurts us to hold on to that term in the core vocabulary in the way we talk about the spec
... I also think we should hold onto it in our semantic vocabulary so we can make the distinction where needed
... I think all the examples in changes are, we are with.you all the way till you said "get rid of credential"
... lets change to use the verifiable credential in types and make the distinction, and then in the data vocabulary have both Credential and VerifiableCredential
... so we reflect where consensus is today

<nage> +1 ^^^

<burn> +1 to manu

cwebber2: so I think I'm fine with that
... as for action on what that means, we should update all examples in the spec
... so those with proof say VerifiableCredential and those without just say Credential

manu: +1, though DavidC might push back on that approach

JoeAndrieu: in terms of the type, shouldn't it always be Verifiable Credential
... we are not suggesting that those without proofs have a different type

manu: That might be a point of contention

<manu> +1 to take discussion back to PR

<manu> and honing it on specific changes.

stonematt: time check, this discussion should go back to the PR? We have 10 minutes to continue on this or move onto test suite

cwebber2: I can capture that in the PR, I think there is just one small remaining issue to resolve in the PR

Test Suite Update

stonematt: now on to test suite update
... cwebber2 or manu?

cwebber2: I have been working on the test suite and did refactoring for a couple of things
... when we last left our test suite we had written up a spreadsheet of tests that were/weren't possible, and we have made those into TODOs
... there are two sorts of changes in addition to added tests
... one is adding stuff for generating nice looking reports
... the other is previously all the tests are just "here is some data" --> verified/not verified
... now there are tests that require pre and post checks in code/logic to check expectations about information that must be validated about the output
... coding those in is going on now
... revocation is tricky, because we need some sort of revocation method, credential status 2017
... that is where I'm at, the goal is to have most of the tests written and at least enough that someone who is there can run it and show graphical output of the tests passing and failing

<manu> yaay, thank you cwebber !!!!

<burn> yes, thank you!

<cwebber2> :)

<dlongley> +1

cwebber2: the test suite must be run against an external thing
... we are trying to get the core infrastructure in place but it might not be easy to hand out any of these items
... the ones where you need extra manual logic are more complicated and I'm not sure if engaging someone else will be worth the time cost.
... when I am further along I will reapproach Yancy

stonematt: are there other tasks we can share with Yancey

cwebber2: I will try to look today

<Zakim> burn, you wanted to comment on Chris' approach

stonematt: it is one minute to the top of the hour. burn, do you want to close us up?

burn: prioritizing the list of examples is very helpful. I have never seen a testing effort that is not setup in a way where multiple people can contribute.
... it is very worthwhile to figure out how to make that happen

stonematt: thank you again to cwebber2 for your focus on this
... thanks everyone!

<kaz> [adjourned]