<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html

<burn> Chair: Richard Varn, Matt Stone, Dan Burnett

<burn> Meeting: Verifiable Claims Working Group

<scribe> scribenick: cwebber2

<burn> scribe: burn

<scribe> scribenick: cwebber2

<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html

varn: anyone new who wants to introduce themselves?
... if not, anyone want to volunteer to re-introduce?

Colleen: I'm Colleen Kenedy, I'm at Pearson VUE, I'm head architect managing credentials... we also have integration with Matt Larson's team working on badges

<dlongley> s/normally "DavidC" I think//

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
... 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

Use cases status check

varn: Is Joe on?
... that appears to shorten our agenda. No worries, will move on

Data Model spec discussion

varn: we want to talk about pull request 67 in particular, https://github.com/w3c/vc-data-model/pull/67

manu: I think the pull request is going fairly well, we've had input from 5 people so far

<stonematt> accordin got github there are 6 PR participants including manu :)

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 (??)
... I'm happy with the feedback provided so far

<manu> Link to temporary preview of changes to spec: http://manu.sporny.org/tmp/vc-data-model/#core-data-model

manu: apologies for temporary link, we can't preview all images on github
... looking at section 3 core data model; a number of new diagrams describing data model
... moving from claims -> credentials -> profiles
... 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.
... 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

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.

manu: yeah, the reason that is is that there was confusion around how we nested things
... most common thing we talk about are claims, which are bundled into credentials which are bundled into profiles
... and then we start layering things on top of it

stonematt: yes I wanted clarification to make sure it was as expected for minutes
... 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

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.
... 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.

<dlongley> there was more than one way to interpret what was in the spec before -- and people *did* interpret things in different ways.

<dlongley> we're trying to eliminate that confusion and "pick the right interpretation" (and the one that matches implementations)

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

stonematt: sounds like we're refining terms we've been throwing around

manu: yes

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

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?

manu: data model itself supports having entire driver's licenses, or atomized driver's licenses. Big selective disclosure convo right now
... so the ability to express an entire driver's license or to atomize a driver's license into parts

varn: just making sure you think we can support both

manu: yes

varn: you also say portfolio, which sometimes has some negative connotations?

<dlongley> aspect/profile/view/X

<varn> education community uses portfolio over profile

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

<Zakim> burn, you wanted to ask about possible loss of distinction between data model and syntaxes and to mention my data minimization GitHub comment

burn: I like this, reads better than initial version
... one thing we tried to capture is the distinction between data model and syntax; do you think it's more clear now?
... I'm not sure if new users wil be clear about it

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

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

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?
... we could say that the core data model is informative
... it would be good to get the group's feedback if they agree with that direction or think it's a mistake

<gkellogg> It seems to me that a section that makes no normative statements is informative, and should be labeled as such.

manu: we should start making normative sections as early as that

burn: that was that was important, make sure the normative sections are clearly marked where defining terms
... 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.

manu: can def raise as seperate issue

<dlongley> 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".

ChristopherA: so GDPR (?) and new federal / 5th document both refer to data minimization
... 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

<gkellogg> Data Minimization sounds like using gzip, not using a subset of the information.

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
... the example of over21 and not sending other information is a very common example, both for data minimization and selective disclosure
... big difference is in data minimization there isn't necessarily masking of correlating information to issuer
... 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

<burn> so maybe we want a separate term so we can mask correlating information :)

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.
... could use merkel trees or CL signatures or U-Prove proofs
... back to my Q, I def like the direction that manu is going; it's definitely posing challenges for me though.
... 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
... 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

<dlongley> a "Profile" is not *everything you've collected*, it is a selection of credentials

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
... 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.

<dlongley> it is intentionally just *one view* of someone's attributes ... just one particular subset of credentials

ChristopherA: having it as a box around teh whole thing doesn't quite deliver things
... I'd kind of prefer to show that they can be signed by different keys, etc
... 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
... I think Entity is an important part of the phrase

<Zakim> 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

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
... what you have is a verifiable credential that has claims
... 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

<ChristopherA> +1

<dlongley> it could be that a Profile should have "credential" or "proof" properties for the claims asserted.

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
... not really a profile per-se as ChristopherA said
... profile implies view of person etc

<dlongley> doesn't imply that "everyone has the same view of a person" to me at all :)

nage: one question that gets raised with selective disclosure is, are you presenting an aggregate of claims, or are you repackaging credentials

<varn> I like the phrase nage used: packaged credential

nage: by moving from claims to credentials we've introduced new term discussions to have

<burn> agree with dlongley

nage: so question to manu was credential vs profile (?)

<dlongley> 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.

DavidC: let me talk about ??? issue
... 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
... 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
... my suggestion is each attributes presented as tuple with group id; when presented you can't mix and match because have different group ids

<Zakim> 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

<dlongley> +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

manu: want to make sure at the end of the call we know if we pull in this PR
... 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

<nage> +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)

manu: would like to know whether these questions or concerns should block this PR

<ChristopherA> +1 to ship PR

<nage> No objections to this PR, just want to note these issues so they don't get lost

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

<burn> Agree with shipping PR

<nage> +1 to ship this PR

<dlongley> +1 to PR

manu: so ChristopherA you had said that a verifiable profile implies that one of these things are different, different inspector/verifiers have different profiles

<stonematt> +1 to merge PR

manu: that's exactly the point, there shouldn't be just one profile
... you as the holder are capable of generating `n' profiles
... that way someone can prove they're just seeing an aspect of your profile

<burn> +1 to Manu about different profiles available for subject/holder/id

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
... 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
... it's all about verifying, making claims by entities
... but in prose, I'm asserting it's confusing. very hard for most people to think in those generalities
... so we talk about issuers, verifiers
... to underscore the point, entity is a core part of data model
... I'd like to discuss how to make it apparent
... 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

<burn> 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.

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
... in 3.2(?) counter-signature is required for certain examples
... counter-signature comes from subject/guarian. also used for proof of work in blockchain, etc
... I wanted to highlight there's another set of profiles that go into a verifiable profile etc

<dlongley> 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"

manu: those are separate
... I think those are all the issues you raised?

<dlongley> and potentially "with these terms of use"

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

manu: yes and please raise issues for things you think the PR does not address
... 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
... one thing is confusion/concern around terminology
... still haven't dealt with signatures around u-proofs / cl-signatures

<dlongley> seems to me that it could be done via "proof" in the Profile instead of "credential"

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
... would be helpful to have a concrete proposal that we work on with (???) teams
... happy to help as editor, point out how these signature schemes would fit in there
... that's my first kind of response to you
... Evernym, IBM esp Jan Camenisch, and do some work in community group, and Digital Bazaar is happy to be involved
... 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
... in the future I think we can align terminology by saying credential is a proof
... 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
... so I think that's the terminology alignment we need to work on
... did that raise the issues you raised nage ?

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

manu: well those drive those convos

<varn> 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?

manu: we can see what maps
... a good signal on what matches
... I think we're at the point where we need to see how these things work concretely

varn: who's going to be the lead on this?

manu: I nominate nage :)

nage: that's fine
... we didn't want to distract others, but at this point I think it's an important discussion

<varn> Jan the IBM guy

manu: to the chairs, Jan Camenisch has also been talking offline on how to get those integrated
... 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
... you could mix them to do something to do something you never wanted
... 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
... 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
... 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
... do you think you could put together 3-4 paragraphs?

DavidC: yes that's fine, I'm not totally sure I have the latest version?

manu: will send latest in an email

DavidC: thanks

varn: we have about 3 minutes or so left

<TallTed> 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.

ChristopherA: I think that a lot of this discussion is about data minimization etc, needs to come back to data minimization
... 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
... we need to be careful and not just pick one. has real impact on data model / naming

<nage> 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

<dlongley> 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

varn: last item is we'll move 3.2 to next meeting; any quick suggestions for agenda

manu: wait I want +1s on mergin PR

<nage> +1 to merge the PR

<burn> +1

<dlongley> +1 to merge the PR

<gkellogg> +1

<amigus> +1

<varn> +1

PROPOSED: Merge PR 67

<Charles_Engelke> +1

<MattLarson> +1

<bigbluehat> +1

<stonematt> +1 on PR67 merge

<ChristopherA> +1

<TallTed> +1

<kimhd> +1

+1

<cwebber2> +1

RESOLUTION: Merge PR 67

<TallTed> dlongley - again, checking whether you only have 1 car seems a separate question.

<TallTed> "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.

<dlongley> 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.

<dlongley> TallTed: yes, what you've said about mooses there is correct, but that's not what the point of the discussion was

<TallTed> "my car" is not a useful identifier. "my jaguar" may not be either. "vin:12345" probably is.

<dlongley> it was about recombining claims, not about the mechanism/evidence/whatever used by the issuer to determine whether or not to make the claim

<TallTed> again -- what is being evaluated?

<dlongley> that's too down in the weeds, the point of the example was to explain the concept of invalid recombination of claims.

<TallTed> OK -- but the way to explain it is by addressing useless identifiers

<dlongley> 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.

<dlongley> well, not trying to address it, just explain it on this call.

<dlongley> that was all

<TallTed> and the explanation digs the hole deeper...

<nage> 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

<nage> definition" or in this case perhaps "credential definition" that you must inspect along with the claim.

<TallTed> nage - and that's going to be generally true. VC on its own is not enough. It fits into a larger picture.

<TallTed> 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

<nage> yes

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/?? view/ Pearson VUE/
FAILED: s/normally "DavidC" I think//
Succeeded: s/(???)/CL signatures or U-Prove/
Succeeded: s/normally "DavidC" i think//
Present: Adam_Migus Benjamin_Young Charles_Engelke Chris_Webber Christopher_Allen Dan_Burnett Dave_Longley David_Chadwick David_Lehn Gregg_Kellogg Kim_Duffy Manu_Sporny Matt_Larson Matt_stone Nathan_George RichardVarn Ted_Thibodeau colleen_kennedy
Regrets: Liam
Found ScribeNick: cwebber2
Found Scribe: burn
Inferring ScribeNick: burn
WARNING: No scribe lines found matching previous ScribeNick pattern: <cwebber2> ...
Found ScribeNick: cwebber2
ScribeNicks: cwebber2, burn
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Aug/0003.html
Got date from IRC log name: 08 Aug 2017
Guessing minutes URL: http://www.w3.org/2017/08/08-vcwg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.