<manu> scribe: Manu_Sporny

Agenda review, Introductions, Re-introductions

<inserted> scribenick: manu

burn: We are going to cover our standard agenda and putting together TPAC agenda... less than 2 months away.
... We need to talk about test suite update...

<Zakim> manu, you wanted to suggest some items for TPAC

burn: Any first timer's today?

<stonematt> Welcome Daniel Hardman!

DanielHardman: Hi, Daniel Hardman from Evernym. Interested in VC spec in general, interested in process on harmonizing wrt. ZKPs.
... I'm also a member of the Sovrin Technical Governance Board.

Action Item Review

<burn> https://goo.gl/V4XTBT

burn: I believe action item review is quick, don't believe there are any.
... confirmed, no open action items.

Assign owners to unassigned issues

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

burn: 3 new issues... accessibility comment -

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

burn: There were two comments, 2nd comment is already an issue in Github.

stonematt: Editorial, we need to make sure we have image captions everywhere.

burn: wrt. accessibility - they noticed we have an extensive security/privacy section... they'd like to see an accessibility impact statement in addition. They'd like to work with us on that.
... Who can move it further with a11y group?

tzviya: I made the statement, I can work with them... what's the timeline?

burn: We are hoping to be able to issue a CR document before TPAC.

<Zakim> manu, you wanted to say that's unlikely at this point.

burn: I suggest having the review before TPAC, within a month.
... That should be a good amount of time.

tzviya: That should be fine.

<stonematt> BTW, Accessibility review issue #1 is https://github.com/w3c/vc-data-model/issues/225

burn: Coordinate with PING during review process... we had a nice review call w/ PING.

<Tim_Tibbals> Sorry I was late as well.

burn: David Chadwick volunteered to do that.
... Anyone else interested in doing this instead of David Chadwick?

*crickets*

kaliya: I'm interested in helping w/ PING review.

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

burn: Also, help Tzviya if you can.

https://github.com/w3c/vc-data-model/issues/224

burn: We're looking for someone to help the conversation proceed... it could be Daniel Hardman, but could be someone else.

DanielHardman: I'm willing to help on it -- I think there is an impedence mismatch in the mental model... assumption that terms of use will show up during presentation... need someone that has knowledge of previous discussions to work with me.
... I can't drive it forward because I lack context.

burn: Let's leave this without an assignee for now... this doesn't mean no one is paying attention, but no one is volunteering yet to drive this.
... Moving on to https://github.com/w3c/vc-data-model/issues/225.. assigning to manu.

Status update on external review of Data Model Spec

burn: Nothing else that I'm aware of at this time, no new reviews.

Possible TPAC topics

<inserted> scribenick: dlongley

manu: One of the best things about TPAC is face to face time with other groups. I don't know if the chairs have started trying to set up quick meetings with other groups. PING might be really good, WebAppSec/security whatever the current security thing happening is.
... Just so we are reaching out to those groups before CR (probably) just so they are aware as a gesture and so we're treated more nicely before the vote.
... Potentially privacy, security, and I don't know if the TAG would be an interesting one to do or not.

<kaz> TPAC schedule - Thursday/Friday

<inserted> scribenick: manu

burn: Any other suggestions?

stonematt: We have a couple of topics -- refresh service, thought discussion came up in last day or so... cryptoregistry? items we should do F2F?
... What about cranking through issues, close stuff?

<Zakim> manu, you wanted to suggest Are we rechartering?

<kaz> VCWG Charter

<inserted> scribenick: dlongley

manu: We might want to discuss chartering or not rechartering. There are a lot of calls and people are very busy. At the same time, there's a lot of work for the full stack, LDS signatures/proofs, so on.

<inserted> scribenick: manu

tzviya: Manu said most of what I was going to say - we want to discuss relationship w/ CCG -- when the group ends/continues... if this group is closing... figure out maintenance model.

<TallTed> +1 clarity of relationship between groups is vital

kaz: have two points
... 1. We should clarify whether this group would like to extend the current work or go to another topic
... 2. W3C Project Team is working on maintenance.
... how to maintain specs generated by closed groups, etc...
... We are still discussing that.

burn: The thing that takes the longest to arrange are joint meetings, so bear with us as we shift our TPAC agenda to accommodate other groups.
... Anyone else have any input on TPAC agenda?

kaz: With respect to joint meeting - working w/ Web of Things WG... do we want to meet with them?

manu: Yes, please, let's meet with them! :)

<TallTed> also +1 to considering extension of current work (vs recharter for new work), as I think we're getting a better/different understanding of this work than was previously held

Data Model PR review

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

<inserted> scribenick: dlongley

manu: Oldest to newest order... Lovesh is in the group now, IPR commitment is done. I assumed that was happening in parallel and processed the issues.

burn: His IPR has been approved that he's in the group, but there are still issues with it not reflecting properly in github, but it's ok to go ahead and merge and of his PRs if github will let us do it.

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

manu: I'm looking at #213 right now, which is a fairly large PR.
... So Daniel, this is where I hope we can make progress on the call. I see a number of things you're changing in this PR that you're also changing in other PRs. Do you want us to drop this one?

daniel: this is one of the problems with the tangling interdependencies. I included an example in one of the PRs that was also in one from Lovesh. Whatever order we pick, if one is mature let's merge that and then I'll go edit others to remove redundancies.

manu: Ok, I'm going to push off #213 if that's ok with you because I think a lot of that can get in from the other PRs. Let's deal with #214-#220 and deal with those first and then update #213 with what's not there later.

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

manu: Currently, for a long time, we've had this ecosystem with an Identifier Registry at the bottom, what we kind of mean is things like DID ledgers. As Lovesh has pointed out, it's important for this registry to also have cryptographic material. I haven't heard back from Lovesh yet, and maybe we can call this thing a cryptographic material registry or registries.
... Whatever term we pick we need to be inclusive. People will use URL identifiers, potentially the SOLID team at MIT, other people will use cryptomaterial that's strongly identifiable and others will use ZKPs with credential schemas and things of that sort.
... The suggestion is to change the name to cryptographic material registry. I'm waiting on a response from Lovesh.
... We do need to discuss this in the call because this is not an editorial change; we're expanding the scope of the identifier registry to make sure it's compatible with some of the ZKP stuff that Evernym is doing.

<inserted> scribenick: manu

burn: Let's give this 5 minutes

<mike-lodder> Where are the resources I can review for the ZKP stuff? Is it just lovesh's PR or somewhere else

<nage> If you are using blinded signatures, you may be anchoring on the crypto, rather the identifier no? (just pointing out that we might need to clarify a lot more if we try to keep the current name)

dlongley: It might be a better idea to call the item that lovesh is talking about as a separate piece of architecture, rather than renaming the identifier registry. These components may be optional components... we may not need to mention them in the model. Maybe we can push them off to an advanced concepts section. If we don't have a clear story about those registries up front, that might not be good. This is not necessarily a requirement... ambivalent about

changing the name, maybe we need to talk about advanced concepts?

dlongley: How we relate to cryptomaterial used elsewhere.

TallTed: Any time I hear about registry, I get concerned.. especially in a data model spec. Identifier registry says "We are going to try to keep track of every identifier..." that's madness and beyond.
... I can't imagine doing that.

<Zakim> manu, you wanted to clarify.

<inserted> scribenick: manu

burn: This may take more time... next step?

<inserted> scribenick: dlongley

manu: I think the change is easier than it may seem. So, Ted, we're definitely not doing what you're concerned about us doing. These identifiers are more or less cryptographic identifiers, and only those that you want to make public. If you came to another conclusion from reading the spec we need to clarify.
... From Dave Longley's viewpoint, we did actually have a discussion on the strategy of how we do this before, with the holder registry. We don't put that on the diagram, the holder repository doesn't go on that diagram.
... That may be the approach that Dave Longley is suggesting.

<dlongley> +1 I am

manu: I don't think anyone is arguing against the concept -- we just need to make sure we express it. Maybe if you go into the Advanced Concepts section you can talk about these things and ZKP and so on, without hitting people upfront with it.
... Dave Longley and I can take some of this offline and look at putting it in the Advanced Concepts section.
... Any objections to that approach?

none

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

manu: Moving onto #217.
... This is somewhat related to the ZKP credential stuff. Changes to the core data model. There's some things here that have been removed. I provided feedback to Lovesh and we're waiting on comments from him.

<TallTed> I would suggest not using "registry" if we're talking about"personal/organizational/private/local stores". which might be the better name...

manu: Ways that the core data model was changed, impedance difference with the group.

burn: Daniel are you able to convey a little more of a description than "sign off by"?

daniel: There was a two page document that was written and people told us it was too detailed.

burn: There's probably a medium between a two page document and nothing.

manu: I forgot to hit submit on review comments, my bad!
... Let me redo it or find the tab where I did the review.

daniel: I will work with Lovesh to add some better description.

burn: I'm not looking for a big description, it's just so that someone who looks at this from the group would understand what's going on and perhaps a pointer to the two page document.

manu: If we get some things straight in #220 it makes #217 easier to pull in.
... Anything else on #217 before we do #220?

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

nothing

manu: Daniel and I have been going back and forth for a while on this one which is great. We're hammering something through that will work for the group.
... Only one thing that remains if we can resolve on the call and other folks review we can pull the PR in.
... Daniel can you do an intro to this PR?
... This one has a good summary at the top but can you talk about it here on the call and what you're trying to accomplish?

daniel: Basically we wanted to nuance a little bit about the assumptions on what a presentation might be. As it exists on the spec today, it says that a presentation is directly composed of embedded credentials. We're suggesting that there could be a couple of different ways to do it instead, one is exactly that and another is to put material that derives from credentials without putting the credentials in directly.

manu: That's great. I think the definition has been expanded in a way that the group has meant for a while but it was good for someone else to go through the spec and pick out the places where the definition didn't work for ZKP style things.

<manu> https://github.com/w3c/vc-data-model/pull/220/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR1037

manu: There's a specific example where we include a ZKP style credential. The thing in the claims section ... that's going to look very foreign to folks. The suggestion is to pull that out and put it in another PR or in another issue so we can discuss exactly what the format looks like.
... If we do that then we can pull #220 in.
... Then it will take a while to work through what the ZKP style data format is suggesting. I've got some proposals on how to do that but I didn't want that discussion slowing #220 from getting into the spec.

daniel: Yeah, sure. I can do that in an hour or two after this call and have it in the format you're looking for.

manu: If anyone else wants to review this, please do it, as quickly as you can.
... I think it's aligned with what the consensus of the group is.
... I'm going to pull it in after Daniel makes his changes unless there are any objections to me doing that.

no objections

manu: That's it for the new outstanding PRs. We do need to talk about `refreshService`.

<Zakim> stonematt, you wanted to say let's discuss the refreshService PR #210 quickly https://github.com/w3c/vc-data-model/pull/210

<scribe> scribenick: manu

stonematt: manu and I had misremembered what we're doing about the refreshService... is this going in the spec or not?
... my memory is that we were doing this, but were deferring delegation.
... refresh service was a part of the discussion.

<dlongley> scribenick: dlongley

manu: I thought I heard group members say kill it. Specifically Ted said "this will create a lot of discussion, we should kick it back and not include it in this version". I think Mike Lodder agreed with him but Dave Longley said he thought Mike was responding to something else.
... If they could respond it would be good.

<mike-lodder> No I agree to push it back

manu: I feel like we should put something like this into the spec. A service the holder can use to go renew a credential that has expired would be of benefit. David Chadwick had a concern about exposing that to the verifier but we can put it in the presentation from the issuer to the holder to avoid that ... but that's moot if we aren't including it at all.

<mike-lodder> Yes a later version not now

stonematt: I want to point out one detail to remind the group. The issuer has an opportunity to let an attribute in a claim be a refresh service. We wouldn't be codifying a mechanism outside of the claim itself for this kind of information if we defer this.

<mike-lodder> +1 to TallTed

TallTed: Roughly that -- you can put anything in that you want so it's certainly possible to include such a URI along with everything else. Whether it's inside the credential or outside, there's nothing that prevents it. It is a chunk of work and if we're extending the work of this group we could do it. Everything is interdependent. I don't think this is vital for 1.0, it may be an enhancement later after some number of issuers/holders/etc try it some way.
... We get to see how it works in the real world and then it can be codified.

<Zakim> manu, you wanted to mention Digital Bazaar is going to do this anyway.

TallTed: Not everything can be standardized before everyone does it.

manu: Digital Bazaar will need this feature so we'll do it anyway, would be nice to have blessing of the group, will try to do something aligned with current thinking of the group. Sounds like Matt and myself want it now and Ted and Mike wanting it later.

<stonematt> Advanced concept?

manu: I don't know what to do at this point, if we don't have more people talking.

<scribe> scribenick: manu

burn: The typical way to do it is to define something and get agreement... in time, then great, if not, it gets deferred.

<Zakim> kaz, you wanted to provide some more information on the GH IPR problem

<kaz> https://labs.w3.org/hatchery/repo-manager/pr/open

kaz: PR 208 and 214 are ok - good to go
... but there are still some problem with PR 213 and 217 - working with the W3C Systeam to resolve the problem

burn: Thank you for input lovesh and Daniel Hardman... we appreciate your input.

bburke: I don't know how refresh is related to verifiable credentials... seems unrelated.

<daniel> Thanks for the call, folks. I have to drop but will continue to interact via email, PRs, etc. See you next week.

[adjourned]