Verifiable Claims Working Group -- 15 Aug 2017

Agenda Review

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

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

Agenda

<stonematt> Add Test Suite discussion

<manu> stonematt: Data model spec discussion, guest speaker, privacy security discussion, and reserve time to talk about issuing and verification.

<manu> scribe: JoeAndrieu

stonematt: adding test suite discussion to agenda

Introductions

stonematt: Any new members for introductions?

<stonematt> Re-Introduction: Dan Burnett

burn: Background in speech recognition. WOrked in W3C and IETF ~ 15 years. Involved because I'm personally interesting in this "Identity" problem. Solving it without using "identity " per se.

Taqanu and Balázs Némethi

Balazs: Hungarian founder of Taqanu.

<manu> https://www.taqanu.com/

Balazs: trying to figure out solution for banking for refugees
... Interested in how identity can be looked at from different angles

<Balazs> https://www.taqanu.com/

<manu> Taqanu is focusing on financial inclusion and identity. It uses new technology and financial payment tools to identify and verify individuals - allowing for access to the financial services that will accelerate integration into new lives and new homes.

<Zakim> manu, you wanted to frame

manu: Over past few years, we've been talking about refugee crisis. A number of us are also involved in web payments group. Taqanu is at the intersection of several W3C groups.
... payments group, this group (VCWG) which lets you establish identity and move claims over the web
... interesting to have people interested in using what we're creating here. Today the refugee conversation has been largely academic, where what Balazs is doing is bringing it home.
... opportunity to get his input on what tech he could actually use.

Balazs: just shared website about how the project started and what we've done in the last 1.5 years
... Summer 2015 was a trigger. Living in Norway and having trouble open bank account, I started looking at how refugees would do it.
... Without access to a bank account, it is extremely hard to participate in society
... It was clear that the way identification is being done--these people are fleeing violence--so many people have a background and education but no way to prove who they are
... Most of these people in this refugee crisis, actually have a smart phone. It's the one thing they are most likely to have.
... We know that data is generated throughout out lives.
... if we can connect that data along with your proof that you are a human being, that should help the situation
... our digital life is built on owning a bank account and bank card in Western Society
... how we are looking at the problem: banks are unwilling to do it because refugees aren't interesting customers. Not a lot of $$$, at risk for deportation, living on support.
... banks have little motivation to onboard refugees
... We are working together with UK financial authority ? innovation hub, how it would be possible to do digital only identification and verification
... bringing in reputation network or other identification that are non-governmental ID
... the way to start the process is a holistic move. Anyone who has a right to stay in country, you have right to bank account.
... Anyone waiting for asylum has right to wait for determination
... Even if we could approve the solution, there is risk about onboarding these risky population
... the holistic approach: digital footprint, data aggregation, plus payment method.
... we have various partners and lots of additional questions to resolve
... at this point things are still theoretical, but we are driving to answers
... anywhere in the world, financial inclusion is a big issue

<Zakim> manu, you wanted to ask Joe to engage

sure if you scribe

<manu> JoeAndrieu: Your work sounds amazing and I'm very interested in learning more and engaging more deeply.

<manu> JoeAndrieu: The way you describe identity, are you seeing biometrics as a part of that? Or is identity more emergent?

<manu> Balaz: We may need some basic identity w/o biometrics, but we are also looking at additional hardware for biometrics. So, there may be a requirement there.

<manu> JoeAndrieu: So, you're saying your approach does have Biometrics anchored in?

<manu> Balázs: Fingerprint or Face Recognition - that may be an added feature since not every phone has a fingerprint reader. We may be able to do face recognition/matching... but we are really looking at what a cheap smartphone can deliver first.

<manu> JoeAndrieu: So your baseline is the inexpensive smartphone.

<manu> JoeAndrieu: What's the architecture that you're planning on using? centralized? distributed?

<manu> Balázs: We are approaching this from a self-sovereign direction, where people own their data. We do not want to take the Facebook, centralized approach. We want this to be a good tool for society. We are participating in the Decentralized Identity Foundation as well.

I'd love to get your feedback on http://bit.ly/joram100

<manu> JoeAndrieu: Great, thanks - cool work - I would like to get some feedback on the Joram paper.

<manu> JoeAndrieu: This was an academic view of what an architecture for refugee identity could look like - would love to get feedback on that.

picking up scribing

<Zakim> manu, you wanted to ask about next steps at the end, after everyone is done.

manu: let's have some plans to engage Taqanu
... alignment on goals
... interested in self-sovereign, refugee crisis, individuals owning data
... now to figure out how to take action
... maybe joe could integrate Teqanu into existing use cases
... or Teqanu could try out our tech in the field
... but maybe we're a couple months away from that
... maybe joe could get some more requirements
... and see if we are meeting those
... clearly a lot happening on regulatory side. Balaza is going to be dealing with that for a couple years.
... but we can probably help the work by incorporating Taqanu's needs in our requirements and subsequent development

Joe: totally

burn: we had some disconnections.
... manu is reconnecting
... now back

Introduction of Test Suite

<manu> https://github.com/msporny/vc-test-suite

manu: here's a temporary link to test suite
... goal is to get to brass tacks on VCs. signature mechanisms, what's required, etc.
... whenever we use an example in the spec, we'll use it in the test suite
... there's a general structure: composed of subsuites. Each subsuite tests certain things.
... We are testing for datamodel v1.0.0
... may have stuff for DIDs

[I missed one]

scribe: meant to be a test suite for all things Verifiable Claims
... not necessarily just for the VCWG
... We are going to have to check in private/public keys.
... These should be test-only! Never put into production
... Then directories for each subsuite
... Not sure how we are going to do it. Might use W3Cs test tech. But that may be more heavy handed than we need.
... Our tests are likely to be pass/fail. Fairly simple.
... implementers are going to have to talk to one another to figure out what goes in
... first version is minimal viable credential
... once we have at least two implementers who work with that suite, we can move on
... these are suggestions. open to ideas. please add a pull request.
... This should also be pulled into the W3C organization, which Manu can't do.

burn: Liam?

manu: I've made Liam a collaborator. So just need to transfer ownership.

[misc github logistics]

burn: any other comments on test suite?
... next item: use cases

cwebber2: not sure I'm prepared to ask this question. I wanted to ask for input about how the tests will look
... will we end up generating claims that other sides will verify?
... sometimes these things get complicated
... also, we're using JSON-LD?

<Zakim> manu, you wanted to provide some thoughts on C

manu: all good questions
... at a high level, we may want this to be super lightweight. no protocol, no client-server anything
... not specifying an API, protocol
... its about whether or not the data structure is valid

<burn> +1 to lightweight. That is all that is appropriate for this spec at this time

manu: in the future we will need a protocol, so we should take that into account in our design
... second thought is, the test needs to be against something concrete. Haven't decided if its JSON, JSON-LD, or XML

<nage> Sovrin's implementation is more of a JSON serialization

manu: currently JSON-LD is most broadly implements, but we're open to JSON or XML if there are implementers want to step up

<nage> but not really, as the CL signatures have their own sort of serialization

manu: The spec is currently a bit in the abstract data model.
... These are the topics we need to discuss as a group

Use Cases status check

thanks

<manu> Burn: What's the status of the use cases document?

<liam> [we'll need to include an appropriate test suite liecence]

<manu> JoeAndrieu: I haven't done anything yet, but do have a question - what's is the best way for me to get up to speed on how to do that?

<manu> JoeAndrieu: I just need some help to get up to speed on how to do that. What's the best way to get bootstrapped into that.

<manu> ACTION: Manu to help Joe get up to speed on spec editing. [recorded in http://www.w3.org/2017/08/15-vcwg-minutes.html#action01]

<manu> JoeAndrieu: I'll try to have something to report to the group in two weeks.

Status of PR 67

burn: looked like a thing, but its not a thing. moving on
... only 10 min left.
... Let's look at PR 69

PR 69: Add section on bundling dependent claims.

manu: David?

<manu> https://github.com/w3c/vc-data-model/pull/69

david: if we have a claim with several attributes, how do we handle mix & matching without violating issuer integrity
... suggestion is adding a group id, and each claim has an associated group id
... that way the inspector would know if claims get inappropriately mixed and matched

manu: we had a section not filled in in the spec in the privacy consideration sections. I put first part of David's input into that section.

<manu> David raised it as a separate issue here: https://github.com/w3c/vc-data-model/issues/70

manu: David raised this as a separate issue
... Typically in privacy, we tend to propose the issue, then discuss solutions, then eventually get to a contribution in spec
... maybe we should go back & forth in the issues, then probably a future telecon around the issue
... Important nuance between data minimization and atomization of claims and what David Chadwick is proposing

<Zakim> JoeAndrieu, you wanted to talk about atomized

<manu> JoeAndrieu: Clarification - it sounds like what David is proposing is a way to limit atomization, but underlying claims aren't further atomized.

david: we want to support atomization. so each credential has only one claim.

<manu> DavidC: The issue is how do you stop abuse by the Holder, who has all the atomized credentials.

<stonematt> concern here is that the holder can't combine atomized claims in a way that an investigator won't mis-understand relationships

david: but what if the credentials are bundled together in ways that are never intended

manu: may be the same thing, but stated differently
... this is why its nuanced and we can use further conversatiosn

nage: definitely a deeper topic

<manu> Yes, agree with Nathan, that's what we need to discuss.

nage: may be ways to address this better. we'll need to take this up and work to address it

<dlongley> +1

<Zakim> burn, you wanted to ask about next steps

burn: anything more to do before we take action?

manu: we can pull in the PR. That's essentially an edit in Privacy section, aka, requirement not solution
... we can describe the problem and say we are working on it.
... with an issue marker

<burn> ACTION: Manu to apply PR 69 with issue note [recorded in http://www.w3.org/2017/08/15-vcwg-minutes.html#action02]

manu: followed by further discussion

burn: want more people involved in writing text
... especially in privacy and security
... so if you see something missing. have something to add? please add a paragraph and create PR
... we'll bring this up again in future calls.
... Thanks, all.

- DRAFT -

Verifiable Claims Working Group

15 Aug 2017

Attendees

Contents