14:48:00 RRSAgent has joined #vcwg 14:48:00 logging to http://www.w3.org/2017/08/08-vcwg-irc 14:48:20 rrsagent, make minutes 14:48:20 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 14:48:25 rrsagent, make logs public 14:48:36 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html 14:48:48 Chair: Richard Varn, Matt Stone, Dan Burnett 14:48:57 Meeting: Verifiable Claims Working Group 14:52:08 nage has joined #vcwg 14:54:31 present+ Dan_Burnett 14:55:06 Charles_Engelke has joined #vcwg 14:55:50 rrsagent, make minutes 14:55:50 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 14:56:39 Colleen has joined #vcwg 14:56:48 present+ Charles_Engelke 14:57:11 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html 14:57:19 Chair: Richard Varn, Matt Stone, Dan Burnett 14:57:31 Meeting: Verifiable Claims Working Group 14:57:33 present+ colleen_kennedy 14:57:41 rrsagent, make minutes 14:57:41 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 14:59:55 gkellogg has joined #vcwg 15:00:38 TallTed has joined #vcwg 15:00:58 present+ Chris_Webber 15:00:59 present+ Nathan_George 15:01:40 present+ Ted_Thibodeaux 15:01:53 present+ Charles_Engelke 15:02:10 present- Ted_Thibodeaux 15:02:16 kimhd has joined #vcwg 15:02:17 present+ Ted_Thibodeau 15:02:26 present+ Gregg_Kellogg 15:02:28 present+ Ted_Thibodeau 15:02:30 present- Ted_Thibodeaux 15:02:49 varn has joined #vcwg 15:03:00 stonematt has joined #vcwg 15:03:14 present+ Matt_stone 15:03:23 present+ David_Chadwick 15:03:37 Zakim, who's here? 15:03:37 Present: Dan_Burnett, Charles_Engelke, colleen_kennedy, Chris_Webber, Nathan_George, Ted_Thibodeau, Gregg_Kellogg, Matt_stone, David_Chadwick 15:03:39 On IRC I see stonematt, varn, kimhd, TallTed, gkellogg, Colleen, Charles_Engelke, nage, RRSAgent, Zakim, burn, dlongley, robert, manu, dlehn, cwebber2, trackbot, deiu, bigbluehat, 15:03:39 ... ChristopherA 15:04:37 scribenick: cwebber2 15:04:37 scribe: burn 15:04:49 scribenick: cwebber2 15:05:34 amigus has joined #vcwg 15:05:35 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html 15:06:22 present+ Adam_Migus 15:06:26 varn: anyone new who wants to introduce themselves? 15:06:35 varn: if not, anyone want to volunteer to re-introduce? 15:07:03 Present+ Christopher_Allen 15:07:11 Colleen: I'm Colleen Kenedy, I'm at ?? view, I'm head architect managing credentials... we also have integration with Matt Larson's team working on badges 15:07:24 s/?? view/ Pearson VUE/ 15:07:44 liam has joined #vcwg 15:07:56 normally "DavidC" i think 15:08:05 s/normally "DavidC" I think// 15:08:09 MattLarson has joined #vcwg 15:08:49 DavidC: Introducing myself, working at University of Kent in the UK, we have a prototype, have a consultation with the NHS for this work, planning on getting more funding 15:09:19 DavidC: have a publication queued, hope next year we can have an academic journal where we can show what we're doing to the wider world; you may have seen call for papers to the list 15:09:43 topic: Use cases status check 15:09:51 varn: Is Joe on? 15:10:15 varn: that appears to shorten our agenda. No worries, will move on 15:10:25 topic: Data Model spec discussion 15:10:44 varn: we want to talk about pull request 67 in particular, https://github.com/w3c/vc-data-model/pull/67 15:10:46 q? 15:11:07 zakim, who's here? 15:11:07 Present: Dan_Burnett, Charles_Engelke, colleen_kennedy, Chris_Webber, Nathan_George, Ted_Thibodeau, Gregg_Kellogg, Matt_stone, David_Chadwick, Adam_Migus, Christopher_Allen 15:11:11 On IRC I see MattLarson, liam, amigus, stonematt, varn, kimhd, TallTed, gkellogg, Colleen, Charles_Engelke, nage, RRSAgent, Zakim, burn, dlongley, robert, manu, dlehn, cwebber2, 15:11:11 ... trackbot, deiu, bigbluehat, ChristopherA 15:11:11 manu: I think the pull request is going fairly well, we've had input from 5 people so far 15:11:36 accordin got github there are 6 PR participants including manu :) 15:12:00 q? 15:12:01 manu: the background on the PR is that our data model section, people were finding it difficult to get through. confusion between claim/credential/profile. so we have a rewrite of data model section with focus on drastic simplification. trying to use 1 or 2 sentence descriptions. trying to move from claims -> verifiable credentials -> profiles (??) 15:12:05 q+ 15:12:06 present+ Dave_Longley 15:12:09 manu: I'm happy with the feedback provided so far 15:12:19 Link to temporary preview of changes to spec: http://manu.sporny.org/tmp/vc-data-model/#core-data-model 15:12:24 manu: apologies for temporary link, we can't preview all images on github 15:12:26 present+ Kim_Duffy 15:12:36 present+ Manu_Sporny 15:12:40 manu: looking at section 3 core data model; a number of new diagrams describing data model 15:12:45 present+ Matt_Larson 15:12:49 manu: moving from claims -> credentials -> profiles 15:12:58 present+ RichardVarn 15:13:09 q? 15:13:53 manu: feedback on PR has been good, some confusion around profile stuff. we hadn't spelled it out before but now we have. That cleared up some confusions, both Joe and Kim pointed out that examples were problematic; not aligning with data model section. Today I updated that section, json-ld examples are updated. Probably more work to do but can be done in separate PR. 15:14:17 manu: at this point I know of no outstanding requests by reviewers of PR? People seem to be happy, but would like feedback from people on call 15:14:22 q? 15:14:31 q? 15:14:39 ack stonematt 15:15:05 stonematt: two things; one thing on minutes you said we're moving from claims -> credentials -> profiles, not sure that's what you said, more of a nesting of that data model. 15:15:17 manu: yeah, the reason that is is that there was confusion around how we nested things 15:15:34 manu: most common thing we talk about are claims, which are bundled into credentials which are bundled into profiles 15:15:51 q+ 15:15:52 manu: and then we start layering things on top of it 15:16:03 stonematt: yes I wanted clarification to make sure it was as expected for minutes 15:16:24 stonematt: other thing is to check, are we re-interpreting things we already had in the doc? or are we adding new terminology that fits this model better 15:16:32 q? 15:17:08 manu: based on what we've implemented to date, we're aligning specification tech to the implementations. Plenty in specification text which was flat out wrong or confusing as explained. 15:17:44 manu: concept, the way it's structured; none of that is changed. terminology hasn't changed. Issue is that (and there's still an active discussion in issue tracker) is that we've been talking about verifiable claims in a way that was confusing people. We're trying to fix that. 15:17:45 there was more than one way to interpret what was in the spec before -- and people *did* interpret things in different ways. 15:18:05 we're trying to eliminate that confusion and "pick the right interpretation" (and the one that matches implementations) 15:18:07 manu: there haven't been any changes to terminology, changes are to structure and what we call them; reviewers will have to say whether they're for the better or for the worse 15:18:12 q? 15:18:20 stonematt: sounds like we're refining terms we've been throwing around 15:18:23 manu: yes 15:18:40 q+ to ask about possible loss of distinction between data model and syntaxes 15:18:44 stonematt: good reminder that if we're at a spot that feels right, those of us on this call today need to internalize and grok it 15:18:47 Q+ 15:18:51 ack varn 15:19:19 q+ to mention my data minimization GitHub comment 15:19:27 q? 15:19:40 q+ to ask about how signature schemes that distinguish claims vs proofs fit into the updated profile terminology and how credentials differ from profiles 15:19:53 varn: so two questions: one of them on the privacy first part; I agree with what you've said there, when I read it I see that a credential is a set of one or more claims about a subject. One thing is whether a driver's license is a claim about a credential. Where or how would you expect this to be expressed? Is this something we'll deal with later? 15:20:12 q+ to say that the actual expression would just omit certain claims, but signature method would have to support doing that 15:20:18 manu: data model itself supports having entire driver's licenses, or atomized driver's licenses. Big selective disclosure convo right now 15:20:30 q? 15:20:31 present+ Benjamin_Young 15:20:44 manu: so the ability to express an entire driver's license or to atomize a driver's license into parts 15:20:50 q- 15:20:51 varn: just making sure you think we can support both 15:20:53 manu: yes 15:21:08 varn: you also say portfolio, which sometimes has some negative connotations? 15:21:14 aspect/profile/view/X 15:21:40 education community uses portfolio over profile 15:21:42 manu: it's been there for a while, debatable whether portfolio is a good term, eg persona/aspects. it's basically an aspect of your online identity. you're right it has negative connotations; it's something we'll need to discuss 15:21:49 q? 15:22:22 present+ 15:22:35 present- bigbluehat 15:23:00 ack burn 15:23:00 burn, you wanted to ask about possible loss of distinction between data model and syntaxes and to mention my data minimization GitHub comment 15:23:05 q? 15:23:14 present+ David_Lane 15:23:42 present+ David_Lehn 15:23:43 burn: I like this, reads better than initial version 15:24:05 burn: one thing we tried to capture is the distinction between data model and syntax; do you think it's more clear now? 15:24:15 burn: I'm not sure if new users wil be clear about it 15:25:26 manu: very quickly; tried very hard to just use pictures in section 3; in fact no syntax in section 3, hope that will help separate data model from actual syntax which is in section 7. Hope that's a clear separation between those two. I still haven't gone through old text to make sure we didn't lose anything important; your old text is commented out, didn't delete it I want to go through it and make a pass to see what's integrated 15:26:07 burn: I understand you kept them separate, what wasn't clear is... it's hard to tell what's an informative section... I want to make clear that we are defining a data model in that section 15:27:19 manu: I think that's a solid point, I think the current answer (not sure if good enough) is that current answer is super abstract. in section 4 we start pointing out properties; we could make section 3 completely informative. "this is the data model we're talking about". but section 4 is where things are concrete. That's an approach we could take that's different than what we had before? 15:27:28 manu: we could say that the core data model is informative 15:27:40 manu: it would be good to get the group's feedback if they agree with that direction or think it's a mistake 15:27:45 It seems to me that a section that makes no normative statements is informative, and should be labeled as such. 15:27:48 manu: we should start making normative sections as early as that 15:28:07 burn: that was that was important, make sure the normative sections are clearly marked where defining terms 15:28:37 q? 15:28:44 burn: on github I commented on data minimization section, I think selective disclosure sounds great whereas data minimization sounds like we're making a binary compiled version or something. not intended to be a blocker, just didn't want to lose it. 15:28:50 manu: can def raise as seperate issue 15:28:51 my view is that selective disclosure is used more broadly than in a cryptographic context... just like "credential" is used more broadly than just "passwords" or "private keys". 15:28:59 ack ChristopherA 15:29:04 ack ChristopherA 15:29:13 ChristopherA: so GDPR (?) and new federal / 5th document both refer to data minimization 15:29:23 q+ DavidC 15:29:38 ChristopherA: both of them do not define it clearly, just saying that only disclose what's required, but don't clearly define it. that is the regulation, esp in europe 15:29:46 Data Minimization sounds like using gzip, not using a subset of the information. 15:30:45 ChristopherA: that's the wording we need to use for the majority of these approaches. A form of data minimization is selective disclosure. I understand people are using it broader than what crypto community means... unfortunately, the legal word is data minimization. I've been encouraging that whenever we talk about selective disclosure, use the crypto term. it's a bit better defined than the other is. unfortunately 15:31:05 ChristopherA: the example of over21 and not sending other information is a very common example, both for data minimization and selective disclosure 15:31:24 ChristopherA: big difference is in data minimization there isn't necessarily masking of correlating information to issuer 15:31:55 ChristopherA: issuer is other information, etc. It's more masked in selective disclosure version. we'll have to dive deeper. I have one user who's offered to help, but yes it's a challenge 15:32:01 so maybe we want a separate term so we can mask correlating information :) 15:32:26 ChristopherA: either we have to issue everything as lots of small claims easily broken apart and sent out, or we need to support ideas around signatures/etc that allow you to break out small parts. 15:32:35 ChristopherA: could use merkel trees or (???) proofs 15:32:50 s/(???)/CL signatures or U-Prove/ 15:33:02 ChristopherA: back to my Q, I def like the direction that manu is going; it's definitely posing challenges for me though. 15:33:23 q? 15:33:37 ChristopherA: if we go to basic components of verifiable profile; first off that box in the middle that's purple could have multiple verifiable credentials. Each of those could have multiple claims inside it. What separates them is the signature 15:34:05 ChristopherA: it's not entirely clear to me about the counter-signature; what's more important is that not every holder with a verifiable profile sees the same thing 15:34:30 a "Profile" is not *everything you've collected*, it is a selection of credentials 15:34:33 ChristopherA: if I collect a bunch of info about manu from w3c resources I'll have a verifiable profile from his work on verifiable claims. but mortgage company would see a verifiable profile that's different 15:35:00 ChristopherA: part of the problem is also related to figure 5 above it. Issuer signature is added to bottom, but it sort of belongs to the big oveal box around it, because it's signing the whole thing. 15:35:01 it is intentionally just *one view* of someone's attributes ... just one particular subset of credentials 15:35:09 ChristopherA: having it as a box around teh whole thing doesn't quite deliver things 15:35:21 ChristopherA: I'd kind of prefer to show that they can be signed by different keys, etc 15:36:00 ChristopherA: that would address most of my concerns; final thing is we've been using Entity because people want to use for non-people. I see Entity is kind of mentioned sort of in these definitions, but it's kind of more important in some of these examples. Not clear on why the term is just profile or just portfolio 15:36:08 ChristopherA: I think Entity is an important part of the phrase 15:36:21 q? 15:36:27 ack nage 15:36:27 nage, you wanted to ask about how signature schemes that distinguish claims vs proofs fit into the updated profile terminology and how credentials differ from profiles 15:36:29 q? 15:36:59 q+ to respond to Christopher: 1) There can be multiple profiles, 2) entity is the base "thing", 3) issuer signatures do envelope verifiable credentials 15:37:20 nage: when you are using selective disclosure scheme, some of our terms end up becoming strangely problematic. Because we're describing each attribute individually, when you try to do selective disclosure you have a subset of claims from issuer 15:37:29 nage: what you have is a verifiable credential that has claims 15:37:49 q+ to respond to nage - we need a proposal from Evernym / Jan for CL-Signatures - we think we support CL-sigs, but we won't KNOW until it's implemented. 15:38:02 nage: now I'm presenting some subset of claims, and changing signature scheme to have proof of claim; when I start talking about a credential, I have to have a distinction between a credential from issuer and proof I generate to verifier 15:38:14 +1 15:38:17 it could be that a Profile should have "credential" or "proof" properties for the claims asserted. 15:38:31 nage: when we start to present credentials as claims, creates an interesting problem where most of the claims are aggregated into credential to obtain access/service/good 15:38:41 nage: not really a profile per-se as ChristopherA said 15:38:48 nage: profile implies view of person etc 15:38:58 doesn't imply that "everyone has the same view of a person" to me at all :) 15:39:14 nage: one question that gets raised with selective disclosure is, are you presenting an aggregate of claims, or are you repackaging credentials 15:39:23 I like the phrase nage used: packaged credential 15:39:31 nage: by moving from claims to credentials we've introduced new term discussions to have 15:39:31 agree with dlongley 15:39:49 nage: so question to manu was credential vs profile (?) 15:39:51 q? 15:39:51 q? 15:40:00 the whole point of a "profile" is that it's *not* the same view for everyone, it's just one particular view of many possible views. 15:40:01 ack DavidC 15:40:06 DavidC: let me talk about ??? issue 15:40:14 q+ to respond to nage - 1) credentials and proofs, 2) CL-signatures 15:40:49 DavidC: the issuer atomizes that, the whole can release individual attributes. whole problem we have with the data model from the same issuer; if they're issued as separate attributes, you could mix and match and present wrong info 15:41:06 q+ to respond to DavidC - unbundling of claims that shouldn't be unbundled (section of spec - privacy section) 15:41:17 DavidC: Say I'm a member staff in computing, part-time in economics, now I have 4 separate attributes, could wrongly assert I'm a staff member 15:41:41 DavidC: my suggestion is each attributes presented as tuple with group id; when presented you can't mix and match because have different group ids 15:41:50 ack manu 15:41:50 manu, you wanted to respond to Christopher: 1) There can be multiple profiles, 2) entity is the base "thing", 3) issuer signatures do envelope verifiable credentials and to respond 15:41:52 +1 to what DavidC is saying -- and it's the issuer's responsibility to ensure that the mechanisms they use to protect credentials do not allow invalid combinations 15:41:53 ... to nage - we need a proposal from Evernym / Jan for CL-Signatures - we think we support CL-sigs, but we won't KNOW until it's implemented. and to respond to nage - 1) 15:41:53 ... credentials and proofs, 2) CL-signatures and to respond to DavidC - unbundling of claims that shouldn't be unbundled (section of spec - privacy section) 15:42:19 manu: want to make sure at the end of the call we know if we pull in this PR 15:42:34 manu: we have a good number of questions by people on call, I don't know if this specific PR is the place to do it 15:42:42 +1 that selective disclosure mechanisms have to prevent cross-matching issues (Example: new Honda Civic with 10,000 miles and old Jaguar with 500000 miles shouldn't allow me to present a credential that I have a Jag with 10000 miles) 15:42:47 manu: would like to know whether these questions or concerns should block this PR 15:42:56 +1 to ship PR 15:42:59 No objections to this PR, just want to note these issues so they don't get lost 15:43:02 manu: so I just want to make sure we have some closure on this PR so it doesn't grow into a much bigger thing 15:43:12 Agree with shipping PR 15:43:15 +1 to ship this PR 15:43:20 +1 to PR 15:43:23 manu: so ChristopherA you had said that a verifiable profile implies that one of these things are different, different inspector/verifiers have different profiles 15:43:29 +1 to merge PR 15:43:34 manu: that's exactly the point, there shouldn't be just one profile 15:43:49 manu: you as the holder are capable of generating `n' profiles 15:43:59 manu: that way someone can prove they're just seeing an aspect of your profile 15:44:01 +1 to Manu about different profiles available for subject/holder/id 15:44:14 manu: it's not a singleton, an aspect of your identity. I think that's aligned with all use cases in rebooting web of trust etc 15:44:44 regrets+ Liam 15:44:45 manu: you also mentioned that you don't see the word Entity used in here a lot; I wanted to point out that Entity is the core concept. In core section we say entity a bunch as "subclass of entity" a lot 15:44:55 manu: it's all about verifying, making claims by entities 15:45:08 manu: but in prose, I'm asserting it's confusing. very hard for most people to think in those generalities 15:45:16 manu: so we talk about issuers, verifiers 15:45:24 manu: to underscore the point, entity is a core part of data model 15:45:34 manu: I'd like to discuss how to make it apparent 15:46:24 manu: third point ChristopherA made was issuer signatures... there was a Q around section 3.2, which shows issuer info was about all of ??? we should try to make grapyic clearer. Please raise an issue about changing the graphic to make it clearer 15:46:40 suggest 'entity' show up in definitions, not as its own term necessarily, but in each other term's definition to make clear that we don't only expect humans in these various roles. 15:47:13 manu: in section 3 profiles you said you're not sure what the counter-signature is about. the counter-signature is another enveloping signature that is used to do stuff like proof of posession/control. when need to prove you're the ??? the counter-signature is used, eg when the UN counter-signs a refugee 15:47:27 manu: in 3.2(?) counter-signature is required for certain examples 15:47:46 manu: counter-signature comes from subject/guarian. also used for proof of work in blockchain, etc 15:47:56 manu: I wanted to highlight there's another set of profiles that go into a verifiable profile etc 15:47:57 counter signature on a profile: "the identifier in this profile refers to *me* and i sign that i am giving this profile (set of credentials) to the domain `xyz.example.com` for the time period X" 15:48:03 manu: those are separate 15:48:14 manu: I think those are all the issues you raised? 15:48:14 and potentially "with these terms of use" 15:48:38 ChristopherA: yes I'm fine, def some wording/imagery/etc that we're all working on. I think PR is in right direction, we just have to continue to articulate 15:48:47 manu: yes and please raise issues for things you think the PR does not address 15:49:22 manu: on to nathan's questions; I think nathan makes good points, part of issue is that Nathan, I think part of shift from claims -> credentials it's unclear how (???) fits into data model 15:49:30 manu: one thing is confusion/concern around terminology 15:49:44 manu: still haven't dealt with signatures around u-proofs / cl-signatures 15:49:55 seems to me that it could be done via "proof" in the Profile instead of "credential" 15:50:02 manu: loose assertion that it's possible through credential, but since we don't have a concrete proposal on the table hard to assert that it works 15:50:21 manu: would be helpful to have a concrete proposal that we work on with (???) teams 15:50:35 manu: happy to help as editor, point out how these signature schemes would fit in there 15:50:41 manu: that's my first kind of response to you 15:51:21 manu: Evernym, IBM esp Jan Camenisch, and do some work in community group, and Digital Bazaar is happy to be involved 15:51:43 manu: so I think that it could be a collection of claims, or as ChristopherA has argued it's a collection of proofs. It's a proof mechanism 15:51:55 manu: in the future I think we can align terminology by saying credential is a proof 15:52:31 manu: may contain other claims, other proofs, but what enables them are the signature mechanisms we're using. in some cases use public/private key type stuff. in some cases you use cl-signatures. but that's what's slotted into there, as a verifiable credential 15:52:39 manu: so I think that's the terminology alignment we need to work on 15:52:59 manu: did that raise the issues you raised nage ? 15:53:21 q+ to ask how to proceed with the new issues 15:53:30 nage: I think that does seem reasonable, I think ChristopherA is in similar issue where we're not sure how to present what we have... some of the terminology shakes out differently but I'm not sure how to raise those without overfocusing on one implementation 15:53:36 manu: well those drive those convos 15:53:40 need to decide if we agree with concrete proposal and who will be the designated lead to report and keep group informed on progress. who is the lead? 15:53:42 manu: we can see what maps 15:53:48 manu: a good signal on what matches 15:53:57 manu: I think we're at the point where we need to see how these things work concretely 15:54:11 varn: who's going to be the lead on this? 15:54:16 manu: I nominate nage :) 15:54:20 nage: that's fine 15:54:39 nage: we didn't want to distract others, but at this point I think it's an important discussion 15:54:51 Jan the IBM guy 15:54:55 Q+ 15:55:07 manu: to the chairs, Jan Camenisch has also been talking offline on how to get those integrated 15:55:19 q- 15:55:38 manu: DavidC concerned about unbundling of claims; currently an issuer can do an atomized version of claims. concern is can be rearranged in a way the issuer never wanted 15:55:48 manu: you could mix them to do something to do something you never wanted 15:56:24 manu: if the issuer did atomized verions of age and also employment (?), so then credential can be used for something they never intended if they barely checked age 15:57:01 manu: in the bundling dependent claims section in 9.2, nothing is there yet but in security section we have a place to say where it is appropriate to bundle to prevent atomization 15:57:24 manu: we've thought about it and think there's a solution but hasn't been a deep dive. DavidC, this section needs help if you want to help 15:57:34 manu: do you think you could put together 3-4 paragraphs? 15:57:50 DavidC: yes that's fine, I'm not totally sure I have the latest version? 15:57:55 manu: will send latest in an email 15:57:57 DavidC: thanks 15:58:02 ack ChristopherA 15:58:03 varn: we have about 3 minutes or so left 15:58:16 verifying that *university said I am 21* has nothing to do with verifying whether I am in fact 21... blurs things again, it seems to me. 15:58:29 ChristopherA: I think that a lot of this discussion is about data minimization etc, needs to come back to data minimization 15:58:57 q+ to ask if anyone would like to block the PR... or show of hands to integrate PR. 15:58:57 ChristopherA: we do need them in the credentials group, and we need to be inclusive of merkel tree solution (simplest but not as strong correlation-wise), u-prove, and of course cl-sigs 15:59:14 ChristopherA: we need to be careful and not just pick one. has real impact on data model / naming 15:59:15 DavidC: we've also had to address how atomization of claims work because of how we do selective disclosure, I'd be happy to talk about that relative to that paragraph of content if you'd like 15:59:21 TallTed: wasn't a great example, should have used one of the ones from earlier, like "I have a Honda Civic and my car has driven 10,000 miles" and "I have a Jaguar and my car has driven 200,000 miles" ... then recombining to make it seem like the Jaguar only drove 10,000 miles 15:59:30 varn: last item is we'll move 3.2 to next meeting; any quick suggestions for agenda 15:59:36 manu: wait I want +1s on mergin PR 15:59:39 +1 to merge the PR 15:59:41 +1 15:59:42 +1 to merge the PR 15:59:42 +1 15:59:43 +1 15:59:43 +1 15:59:43 PROPOSED: Merge PR 67 15:59:45 +1 15:59:45 +1 15:59:49 +1 15:59:50 +1 on PR67 merge 15:59:50 +1 15:59:56 +1 16:00:02 +1 16:00:02 +1 16:00:11 +1 16:00:12 RESOLVED: Merge PR 67 16:00:31 rrsagent, make minutes 16:00:31 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 16:01:01 present- David_Lane 16:01:14 rrsagent, draft minutes 16:01:14 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html manu 16:01:23 dlongley - again, checking whether you only have 1 car seems a separate question. 16:02:29 "I am a blue moose." I have made a claim. That claim can be proven false upon any examination. But that falsity is entirely outside the question of whether I have made that claim, whether I am qualified to make that claim, etc. 16:02:34 TallTed: so in the abstract, we don't want a situation where issuers create N credentials, each having M claims, that can be recombined to form new, invalid, assertions. 16:02:46 s/normally "DavidC" i think// 16:03:14 TallTed: yes, what you've said about mooses there is correct, but that's not what the point of the discussion was 16:03:23 rrsagent, make minutes 16:03:23 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 16:03:34 "my car" is not a useful identifier. "my jaguar" may not be either. "vin:12345" probably is. 16:03:38 it was about recombining claims, not about the mechanism/evidence/whatever used by the issuer to determine whether or not to make the claim 16:03:43 again -- what is being evaluated? 16:04:01 that's too down in the weeds, the point of the example was to explain the concept of invalid recombination of claims. 16:04:33 OK -- but the way to explain it is by addressing useless identifiers 16:04:39 that, while it's a good idea to allow people to selective disclose certain claims, it is also a potential problem that the issuer must protect against so that the claims they make cannot be unduly recombined to create new, invalid, assertions that they never intended to make. 16:05:01 well, not trying to address it, just explain it on this call. 16:05:03 that was all 16:05:47 and the explanation digs the hole deeper... 16:07:21 TallTed: you are right that how you express your schema and the identifiers at issue is important. When dealing with selective disclosure profiles, obviously the verifier ends up inheriting some of this complexity because they are trying to sort out the mess that has been made. If you have an oracle for the definition of the claim (like a distributed ledger) there is a lot that can be done to help there, but that means you have some type of "claim 16:07:22 definition" or in this case perhaps "credential definition" that you must inspect along with the claim. 16:11:35 rrsagent, make minutes 16:11:35 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 16:12:09 nage - and that's going to be generally true. VC on its own is not enough. It fits into a larger picture. 16:14:17 I get a claim from somewhere that Joe's car has 10,000 miles on it, and that Joe has a Jaguar. It's incumbent on me as a car buyer to know that Joe might have multiple cars, even multiple Jaguars, so I need to confirm the coreferencing (or lack thereof) of these statements 16:17:40 rrsagent, make minutes 16:17:40 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 16:18:06 yes 16:23:31 rrsagent, make minutes 16:23:31 I have made the request to generate http://www.w3.org/2017/08/08-vcwg-minutes.html burn 16:24:46 yes 16:26:26 rrsagent, bye 16:26:26 I see no action items