<burn> scribenick: Yancy

Agenda review, Introductions, Re-introductions

burn: no action items
... looking at most stagnant issues and data model review

blockchain workshop

manu: blockchain web commerce interest group. Nothing solid but chance something will happen. FYI since most of us are not on invite list.

<tzviya> https://www.w3.org/2003/08/Workshops/

manu: headsup from IBM, Sovrin, Evernym, Digital Bazaar etc will be there
... birds of a feather session at tpac but not traditional workshop

Assign owners to unassigned issues

manu: will be a workshop around strong identities and that's it about blockchain breakout

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

burn: wants to talk about closing issues or PR for issue
... issue was discussed 6 days ago and not worried yet on this

daniel: questions being asked are interesting and thinks those are good questions but doesn't have answers

DavidC: happy to take this issue

Status update on external review of Data Model Spec

burn: ken would you be able to introduce yourself

ken: working with Sovrin. working on standards architecture and coding

Most stagnant issues

<burn> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc++-label%3Adefer+

burn: most stagnant issues. Wants to find a way to unstick and keep them moving.
... posted link
... start at top and work our way down
... start with #72
... cwebber2 would you comment

<kaz> issue 72

cwebber2: didn't writup PR
... will make a priority this week

<burn> ACTION: Cwebber to write up PR for issue #72

burn: next is 194

<kaz> issue 194

<Zakim> manu, you wanted to say we have some designs for this...

<daniel> have to step away for about 10 min; brb

manu: want to talk a bit before you submit that PR because of good feedback from customer deployment. may help to have a discussion in working group.

<burn> Manu commenting briefly on 172

cwebber2: happy to have discussion in group or after

burn: needs to login with host code for everyone to showup
...: can't change it now

manu: I see it

<burn> now to issue 194

manu: can take this
...: thousands of vocab words may conflict
... w3c vocab is something google and microsoft does not want to do for schema.org
... jasonld will let you do that but some scary things can happen
... won't prevent anyone from pulling in if they want to do that
... should be clean vocab because of that
... should be able to close the issue (no op)
... nothing to be added as a result
... a completly different issue because of content control is a commment on PR

<manu> ACTION: Manu to respond to issue 194 Dan Brickely, no op, and suggested path forward, then close issue.

davidc: raised a number of questions and would like answers

burn: request for comments
... moving on to #133
... last comment was from manu asking joe if this was fixed
... request for david and manu to look at this
... joe is ooo for next few weeks
... manu thinks we can close if davidc agrees

<kaz> issue 133

<Zakim> manu, you wanted to agree with DavidC, but I think we can close at least this issue.

davidc: all related as a higher generic level, not sure it has been fixed as a whole. might be good to discuss face to face which is more productive than email

manu: agrees with david that there's a higher level meta issue that hasn't been resolved, but we can close this issue because we have a profile id and should be able to close.

davidc: agrees with manu on that

burn: if you think joe is not to be surprised then it's fine to close
... make sure joe is not unaware

<scribe> ACTION: manu to bring it up with Joe

burn: thank you
... next is #200
... not a lot of discussion

<Zakim> manu, you wanted to note what was supposed to happen.

burn: matt and joe are both not present

manu: Matt put in a PR to fix a lot of typos and issues but not noted in issue. I need to close the loop with him to make sure good solid response are made for Clare

<scribe> ACTION: find PR and cross ref with issue

manu: matt addressed 201
... it wasn't 200
... nothing has been done for 200
... 200 is stagnant
... Matt worked on 201

<kaz> issue 200

<kaz> issue 201

burn: matt and joe to review and unstick

<burn> ACTION: Matt and Joe to review 200 and get it moving

burn: leaving 10 minutes to look at PR's
... looking at #209
... duplicate of #128
... wondering why there are two

<kaz> issue 209

<kaz> issue 128

TallTed: the way he reads those two, is one is wishing for default and other is looking for this isn't a default and go look there
... not identical

<DavidC> +1

Davidc: agrees

<Zakim> manu, you wanted to defer, regardless.

manu: is confused because it looks like a duplicate

tallted: 128 is asking for a standard schema and 129 is if not using that standard default what to look against

<kaz> issue 128

<kaz> issue 129

manu: can defer both issues can be done by not specifying in the spec and instead use feature later

<daniel> I am back

manu: not critical and can defer until next specification

<ken> nage: the presence of schema would really help us reason about ZKP functionality relative to the data model, this doesn't mean we must add it now, but it would speed things along

DavidC: types and content is the same. has had discussions if it's strongly verified. In the documentation it has been added to address types.
... here's a type that gets embedded in the schema for it

nage: we have issue with it not specifying the type of encoding. It would accelerate the process to specify.

<Zakim> manu, you wanted to suggest that there is a way to solve this with a single property.

nage: it would speed up the process if we did have it by mapping to crypto

manu: has an idea of how to address with a single attribute. one way is to defer and the other is to get a simple proposal and I might have one.

<manu> yes, dlongley is right

<manu> this will take a little bit of effort.

dlongley: will have to specify and might take more than one attribute which could be more effort than we think

burn: is there a summary manu could do

manu: trying to prevent us from having long features. we run the risk on introducing a feature that isn't thought out well.

tallted: it's a data model how much are we expecting?

manu: the concern is how it acts when we deploy the feature. question is does it actually solve anything?
... data model is simple but does it solve the problem
... validation language example. is an attack surfaced open.

<burn> I think it's fine to ask if this is critical for this version

tallted: thinks manu is thinking beyond scope and protocol
... the model doesn't do that. if YAML or otherwise

dlongley: if we don't have a good grasp of how to do this. It's not simple enough to just toss in the data model.

<Zakim> burn, you wanted to reiterate question about whether we must have this now

dlongley: thinks it's more difficult than just data model and it's a middle ground

burn: Manu is right that we are tying to finish things up
... doesn't think we will have an answer today
... we reserve the right to say this isn't going to be resolved for this version

<manu> ACTION: Manu to work on PRs for 128 and 129.

burn: any objections for how to move forward?

Data Model PR review

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

burn: opportunity for manu to bring up items for how to move forward
... daniel if you can talk about credentials. lovesh don't know if you're being blocked.

manu: suggests DavidC, then Daniel, then lovesh

davidc: had some good feedback from dlongley

daniel: bearer credentials and had discussion in other forum and feels like verbiage isn't right.

lovesh: proposed the change to verify the call cryptographic repository.
... any comment?

manu: still thinks there's a problem with VC
... any input from the group would be good

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