<scribe> scribenick: cwebber2

Agenda review, Introductions, Re-introductions

stonematt: quick review of the agenda

<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2018Aug/0004.html

stonematt: that's where we published previously for the mailing list, plan for the day is to do this, agenda intros if necessary, review of data model spec including feedback from PING, overview of PRs, and if time test suite update
... anything we can add or amend in order of items before we dive in?
... not hearing any volunteers to change, so let's open with introductions & re-introductions
... any new participant on the call?
... brief intro of who you are, so we can welcome you to the group

tim_tibbals: I'm working on the c-ledger project, working with John Best

gannan: I'm new with Digital Bazaar, excited to do stuff with the VC group

Assign owners to unassigned issues

stonematt: next is unassigned issues
... no action items in the running action items list so let's go to assigning owners to unassigned on the agenda

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

stonematt: I'll add a link
... there we go
... couple of new items opened, let's start with the first 212, duplicated syntax section
... opened by elf pavlik

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

manu: I can take it... I can take both

<burn> Both meaning 212 and 211

Status update on external review of Data Model Spec

stonematt: next on the list is the update about the external review
... *looking at notes*
... we obviously had a big meeting with PING last week which many members participated in, that will be its own topic
... we had a couple of other items, the only group we have no response from that is confirming a review is actually our CG
... we've gotten a response from all other groups requesting review that they are starting to review
... who's at the CG who might volunteer to get an official acceptance that they will do review and get feedback

DavidC: shouldn't it be someone in the CG group but who's not in the WG who does the review?

stonematt: that's fine, I'm just asking someone who's here and in the CG to bring it up so we can find a reviewer

burn: I'll bring it up on today's call
... I'll mention we sent an email and ask for it to be taken on as an action item

stonematt: thx dan, that'd be great

PING feedback and response

stonematt: next one is feedback from Privacy Interest Group (PING)
... for those who weren't there, it had several participants from the WG join, we took much of their hour describing and introducing our work
... Manu did a very nice job introducing the goals of the group and the ecosystem, the objectives and ecosystem around what a VC is and how it works
... had a dialogue and feedback from their members asking how it might work
... and how they might proceed with their review
... this was an introduction to get them started on their feedback process
... we introduced the idea that there's a pretty broad spectrum of privacy concerns that VCs are meant to address, from lightly identified to anonymous, to highly identified such as licenses where holder/subject is well known
... they said given that spectrum it'll be difficult to give feedback about privacy to the spec
... second element of feedback I heard was that examples from data model tend to use examples where subject / holder is highly identified. We don't have examples of bearer credentials or ZKPs
... I'm sure there's other feedback items of note
... in case someone wants to add to that summary
... DavidC?

DavidC: yes in the meeting last week when discussing subject != holder I thought manu was going to incorporate that immediately after the meeting, but manu has only gotten to do it today... one concern was that when we met with PING I didn't raise it yet, but there's clearly an extra privacy concern when subject != holder
... I'm not sure if PING will review today's subject != holder text, or if they will see the stuff added today. because I feel there's an extra level of privacy stuff when subject != holder they are unaware of at the moment

manu: sure, so purely because of time, not because we were trying to keep it from them. Just this morning I incorporated David's PR, and I've been doing a bit of rework we might discuss later

<Zakim> manu, you wanted to provide expected feedback.

manu: typically when asking groups to do review and you're still in the draft version you ask them to review the latest draft. We can point them to the latest document
... they understand it's WIP, that said I think that section makes the review more difficult, in that I think you're right in that it opens a new can of worms related to privacy considerations
... I think there are a couple of elephants in the room that we didn't get into
... if you listen very closely, the feedback is "well what we can do is that VCs don't meet the security model for the web"
... I think we need to understand that we're going to hear that the security model of the web is same-origin
... the second you introduce multi-origin you get certain people concerned
... we have to be ready for that concern, I think there's that undertone when talking with PING
... I wanted to call attention to that
... other thing of concern is that the statement was made multiple times, "we don't know where to start"
... "can you narrow it?"

manu: we said "not really, we have a lot of stakeholders [listed] and we're trying to make a general data model"
... a review focused on a single thing will focus on a tiny sliver of the ecosystem
... except for review per the web security model, which we know will be a negative review. third thing I found concerning was focus on bearer credentials and ZKPs. I think our position has always been we have to support it, but I think problem is potentially focusing on something like the over the age of 18 credential, which while useful explaination strategy, in reality I don't know many companies basing their current customer engagements off of that
... concern may be we allow full spectrum of privacy, but many of companies working in this space are working in fully identified realm
... doing things like over the age of 18 credentials are difficult not for tech reasons but for regulatory burden currently
... there's a request that we focus on the more pseudononymous credentials, but concern is that moves us into a toy specification
... so anyway those are some loose thoughts, I think all we can do is wait for feedback
... I think changes we can make are add more bearer credentials and ZKPs
... as for multi-origin there's not much we can do... we are introducing a new security model for the web and we expect that to be a hot debate

stonematt: two things to follow up
... I noticed that 1) it seems like we're coming at this from the perspective of an open world mentality... we want adoption of this. when we chartered the group one of the driving queries we heard were market adoption / organic adoption of this, and many companies we're working with are doing the highly identified part of the spectrum generally speaking
... and this is a data model not a protocol
... privacy enforcement might happen in protocol rather than in data model itself

<dlongley> i disagree that we're suggesting a new security model for the Web, rather, we're just sharing things cross origin in a way that respects the same origin policy (user only interacts with one origin at a time and consent is required to move data from one origin to another)

stonematt: in eg an SQL model there's all sorts of data you can put in

<manu> yeah, I think we can approach as dlongley said... it's just that some people don't agree.

<Zakim> kaz, you wanted to ask who call-in user 6 and 7 are

kaz: who is call-in user 6 and 7?
... who dialed in 5-10 minutes ago

stonematt: if you're on the telephone would you please speak up one at a time

Yancy: *identifies self as 6*

<nage> I agree with the point about protocol issues, Sovrin has been doing a lot on the privacy side, but it is hard to bring up when we are just working on data model. Perhaps we should bring more ZKP concepts into the spec as optional to better show the spectrum?

markus_sabadello: *identifies self as 7*

<manu> nage - agreed, I think that would help.

DavidC: I agree with Matt in that solving the single origin issue
... I wonder if a way out of this is to have a profile document, the profile document would say how you can use this with same origin document

<manu> nage - although, I think we'll still have folks that won't be happy until we make everything either a bearer credential or a ZKP (without any PII).

DavidC: (???) FIDO model
... do you think that's a good way to satisfy PING, is to say it's possible to obey same origin policy

<Zakim> cwebber, you wanted to address how do we deal with open world / broad usage

<dlongley> we don't allow scripts on one page from one origin to access data from another page on another origin ... that would be a violation of the same origin security model -- we simply don't do this or even touch it at all.

<manu> cwebber2: The issue with having such a broad range of applications... I'm surprised to hear that's such a concern. There is a lot of technology developed at W3C that fits into that boat... for example, HTML.

<manu> cwebber2: We are trying to create a general technology that's broad... it's surprising to hear that pushback.

<DavidC> @cwebber -> same origin document -> same origin policy

<manu> cwebber2: Is there a way we can respond with that? This is a general technology?

stonematt: for someone else who was at the call, perhaps jumping to the conclusion that it's the open data model that's the problem rather than the same origin model that's the problem is the nuance we should tease out of this

TallTed: I'm sorry I wasn't able to make the call... similar to what you said earlier about reviewing SQL server, it's less about that and more about reviewing a schema and ontology, and there are no privacy implications to an ontology, it's a datastructure. It's just not relevant
... I'm surprised this hasn't been said, including on their side
... there's no protocol, just a datastructure... and not even a datastructure, it's an ontology

DavidC: just to say something on last call, the verifiable presentation is the protocol

TallTed: the way it's used may have implications, but that's not what we're doing

DavidC: I disagree we're suggesting a new security model for the web... we're just making a data model, which I think fits into what TallTed is saying
... we're not in any way creating a situation or even touching anything where a script on one origin touches another origin

<DavidC> @cwebber DavidC -> dlongley

dlongley: we are talking about sharing information from different sources, but whenever we talk about that informatively we talk about involving user consent in that process. So I don't think we're even touching the security model on the web and don't intend to do it in any way
... we're trying to work within those bounds when workign on things

<Zakim> burn, you wanted to respond to Ted

<stonematt> +1 to dlongley

<Zakim> manu, you wanted to clarify data model, presentation, credential, etc.

burn: +1 to what dlongley just said. we did mention this on the call, and it sounds like all we did was mention it but no we did state that, but sometimes there are subtle issues where certain kinds of privacy implications can be inferred from a data model (or people will try to do that). We didn't focus as much on that argument because I've found that argument doesn't always get us as far as we'd like which is that what we're doing has nothing to do

with the security model of the web, it's irrelevant

manu: I stand corrected, I think that when people look at this work we're doing that it's very difficult for them... they're not familiar with what we're working on, and it's hard to separate what we're working on from what it could become
... it's very easy to map it to a 1984 style future because that's what privacy folks mostly work on, and in some ways we're putting plenty of ways to deal with that
... some people are happy with that, others are upset that if anyone's privacy leaks in the process, it doesn't matter if you took it into account
... what if you have an ashley madison style leak, and now you have signatures and know it wasn't tampered with
... I don't think our biggest challenges will be with the ones dave just made, we're not doing that we're not touching same origin, but I think the same people dealing with this don't have a technical understanding of same-origin
... they're worried about being phished, and making sure that if you're phished that it's not very useful to that person
... the people viewing this are not as sophisticated, I think the argument that TallTed made is absolutely solid but you need years upon years to get that understanding
... but I don't think they may be understood by those doing the review
... but those are the arguments we have
... now for what I put myself on the queue for, I get where Ted's going, but I think Nathan has a solid point which is that there are pieces of protocol that inevitably end up in the data model
... for example we're using VC in the credential handler model
... there's nothing on top of it, no http headers no extra anything, everything is in the verifiable presentation
... that's an example of the data model being reused by the data model
... I think we can make a solid distinction between the two, but there's always a blurring, and the blurring will come from the privacy folks saying "that's what you're designing, but what happens when someone abuses that"

nage: so I think we have to ack a few things, I don't think the views in the group in general might not be universal... I have some disagreements about how some of the privacy issues have been handled, I think most of that is because we've been so focused on the data model part of it
... in order to improve the review I think we should provide advice on how to use it
... i can think of a few issues to make it friendlier to privacy eyes
... I think we need to take a step back, think where a generic web browser would think it's applied, they're probably thinking about web storage
... it's easy in that case to think of data model use cases of eg pulling something out of a wallet
... for those not familiar we probably need to describe those workflows, but doing or saying somethign might help reviewers understand

TallTed: anywhere we have "protocol" in the data model spec is an error. Anywhere we have anything more than the column header names is an error in a data model spec. if we're doing anything other than that we're doing it wrong
... I'm sorry if that impacts the work we've done or going forward, but that's the hazard of the current compartmentalization happening with w3c work
... we have a very specific charter, production list, etc
... it doesn't include how it's used
... it's just a model
... if I'm describing a lion, these are the characteristics that go along with it. If I'm describing a VC, here's what goes along with it
... if there's sensitive information, there's sensitive information, there's use cases for using a paper and pencil
... we'll make it not pass through
... many times we've said we're close to the end of our time
... our focus should not be on what's happening in the CG even if it overlaps
... W3C is broken in a new way than it was 5 years ago, but we have to fight against the things causing us problems

agropper: speaking of a privacy professional on this topic, we might find it easier to convince those concerned if we describe the goal as giving individuals agency as opposed to privacy

<manu> Very good point, agropper.

agropper: eg what you take out of your wallet as a form of agency
... not arguing we shouldn't talk about a data model very strictly

<burn> +1 to Adrian's example of giving control over what you take out of your wallet

agropper: when people ask why we're stepping into a non-single-domain situation, we need to give people agency

bigbluehat: just wanted to say a quick thing from experience with the web annotations wg, we did data model and protocol. we didn't add html integration, we didn't add user interface requirements to the spec, but accessibility is a problem people keep asking about, and I say the spec is a data model and accessibility is a user interface challenge
... I think as TallTed described, I think we should post new advisory board elections
... contact the person in charge and make the case that this needs some new solutioning and discussion

tzvia is a new AB elect

bigbluehat: then we can narrow in on "we're just building a data model"
... in the same way web annotations kept making the argument for that
... we need better signaling in the w3c
... don't let the process choke this work

<Zakim> cwebber, you wanted to ask doesn't this apply to all linked data systems

<manu> cwebber: Just thinking about everything just said - generality that this is a data model spec... seems like complaints apply to literally any Linked Data system that could be built. Is that part of the challenge? Is that part of the issue? Or is this the same sort of origin stuff that have happened in any of the Linked Data systems that have been proposed so far?

manu: there have been plenty of other linked data systems and data models that have gone through w3c that have not had this scrutiny
... plenty of other specs where you could shove PII into it and nothing was said
... I think the issue has mostly to do with the use cases we're dealing with
... since we're dealing with PII use cases people are having a tough time making a distinction between this is just a data model with understanding how it may be used
... I think it's purely an optics thing, about the data use cases we're dealing with
... other groups don't think about their person's name or address
... unfortunately I think that won't get us out

<burn> yes, Manu gave the analogy of a database in our PING call.

stonematt: timecheck, 5 minutes till CG call

gkellogg: so I think this is where nomenclature gets in the way. data model implies something more closed, whereas ontology implies the specification of the way the data links
... if ther was a property with a clear password, and the ontology required a clear password to be present, that would be a clear privacy problem. since anyone can say anything and include data from othere ontologies, there's limits to what can be done about privacy / exposure that could be exposed

TallTed: we've got theoretically a use case document that informs the data model, maybe if we refine it to draw distinction between protocol-relevant and model-relevant that may help
... again, yes, unsophisticated / uneducated people may think of implications outside our realm
... our responsibility is to say this is our scope, you're outside the wall, otherwise we'll never pass reviews
... you don't want a lengthy call with w3c management; it's no fun

<burn> +1 to TallTed

<dlongley> +1 to TallTed

<manu> +1 to TallTed

<bigbluehat> +1 to TallTed

<gkellogg> +1 to TallTed

<cwebber2> +1

<stonematt> +1 to reiterate our scope during review thanks TallTed

TallTed: we've just got to be clear, this is the wall we're working with... the stuff you're working with, make a different charter, it's outside our scope

stonematt: thanks TallTed, I think that's right
... I agree with your comments that we should put +1s to minutes instead of /me comments
... burn and I can talk more about this later this week
... unless more comments we'll adjourn, cya next week