See also: IRC log
<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
varn: Is Joe on?
... that appears to shorten our agenda. No worries, will move
on
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.[End of scribe.perl diagnostic output]