Verifiable Claims Working Group -- 06 Feb 2018

<stonematt> Scribe: Matt Stone

<stonematt> Scribe: stonematt

Agenda Review and Introductions

Dan Lieberman - CTO focused on identity, privacy, and identity

welcome Dan!

<scribe> agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Feb/0004.html

Face to Face meeting update

<burn> Meeting spreadsheet: https://docs.google.com/spreadsheets/d/19Ndqc5pLsTu2ZmP4Wy7OlMOmskQFHPh28sMjW3ugsww/edit#gid=0

burn: chairs to make agenda outline for next week meeting
... will meet at IIW
... JoeAndrieu working through logistics

<scribe> ACTION: chairs to make agenda for face to face

subject != holder

burn: introduce DavidC

DavidC: most use cases suggest/assume that subject = holder, suggests making new section for subject != holder w/ diagram from his email in January
... subject may issuer delegate to a new holder - this is a recursion. should be able to stop recursion at some point
... some cases aren't supported in datamodel -- especailly pets.
... need to document the first and solve the second

JoeAndrieu: curious which cases the DM doesn't support -- which ones?

<burn> David's text (issue): https://github.com/w3c/vc-data-model/issues/106

DavidC: define what it means "DM support it": there's sufficient information in the DM to let you know that the relationship is the crednetial is clear. shows "acts on behalf on" for example

<Zakim> manu, you wanted to note new issues and point out that "subject" and "id" is being conflated.

burn: questions?

<manu> manu: I think we're conflating "id" and "subject != holder" -- will respond to David in comments.

no response.

<burn> David's issue doc: https://github.com/w3c/vc-data-model/issues/106

burn: need uses cases in UC document that reflects these cases. need a review of issue 106, so we can finalize spec text

Report on revocation spec activity

<manu> manu: No new updates -- we need implementations

<manu> manu: That spec isn't going to move forward until we get implementations

<dlongley> stonematt: On the revocation side, I volunteered to work on that.

<dlongley> stonematt: To work on that document/process to bring CG work into the WG at the beginning of the year. I haven't done anything yet, no progress, but it's on my deck and I expect to have more availability for this topic over the next few weeks. I'll bring updates over the next few meetings.

<dlongley> stonematt: Christopher Allen, if you're on the call, I think we were on that list and I'll try to figure out our roles and connect with your offline.

<dlongley> Christopher: Thank you.

<Zakim> burn, you wanted to ask who is working on implementation

<dlongley> burn: On this same topic, Manu said this won't move forward until we have implementations, so is anyone planning on providing an implementation.

<dlongley> manu: Digital Bazaar is planning on doing an implementation at some point but not sure when we'll get to it. Nathan has good news on that front it looks like. If we have two interop that's great.

nage: has an implementation for credential exchange. will work on a json style implementation as well
... would like help from manu and team to make additions to test suite

manu: simple revocation implementation similar to link above

nage: not doint the list version. will do revocation another way. n

manu: need 2 parties to do interoperable implementations. if we introduce a second strategy, we need another implementor
... is there a second?

nage: fabric code base has a similar. Idemix protocol also has simiarl

ChristopherA: BTCR may have an implementation. reservation is that it's a static document at an end point w/ other unverified content

<Zakim> dlongley, you wanted to ask about implementation requirements

dlongley: are the requirements for interops about 2 clients that can check revocation?

burn: intent is to have 2 implementation that can independently check the spec and that it "works" with n>1

dlongley: agree - need to build clients that uses the revocation list or tails accumulator

<Zakim> manu, you wanted to provide opinion in this specific case.

manu: not sure I agree...
... need clients that actually meet the intent of the business goal of revocation
... shouldn't block DM spec. b/c it's non-normative
... need 2 implementation of the same thing
... chose revocation list approach because it's the simplest approach for issuers to implement

<dlongley> stonematt: I was to reiterate what Manu said -- he made my point. If the point of implementations is that we need two, it's an aspect of the data model. We need two issuers that make the list and clients that can verify the validity of the list/credential. Need it to be end to end. If we add another strategy we will need 2 clients and 2 lists/whatevers for that. This turns into a cartesian problem as we add more strategies.

<Zakim> dlongley, you wanted to say i wasn't suggesting two different methods with only 2 clients, but 2 clients required for each revocation method, only 1 list

TallTed: a simple list doesn't need a server implemented. if we have a more complex strategy, we'll need >1 issuers as well as clients

<agropper> +

TallTed: implementors by parties outside of the working group are really valuable and require the chairs to call for implementations more broadly than just on the calls

<liam> +1 to implementors outside the WG being awesome and helping confidence in the spec

agropper: quick question: have we discussed the privacy implication of the list?

<TallTed> it's a note for the privacy section

<dlongley> the answer is yes and if not already captured in the spec (I thought it was) we should make sure to note privacy considerations.

stonematt: yes - that's a reason why there are other strategies in play for revocation

<manu> https://w3c.github.io/vc-data-model/#validity-checks

<manu> manu: We have this in privacy section now -- https://w3c.github.io/vc-data-model/#validity-checks

Update from Matt Stone

<dlongley> stonematt: Pearson credentialing team is shifting its strategy some and it's affecting me and my role. I have learned in the last few weeks that my tenure at Pearson is coming to an end in June. It's going to affect my role as chair in the WG and if I leave Pearson I won't be a W3C member.

<manu> :(((( *super sad news*

<dlongley> stonematt: This is a heads up to the team to let people know. I'll probably put out a call for a new co-chair.

<dlongley> stonematt: Anyone who is interested in stepping into the role that I played I invite you to reach out to the chairs and engage with us.

<Zakim> manu, you wanted to thank Matt for his leadership to this point and participation in the group.

<dlongley> stonematt: I like the work we're doing and it serves an important purpose and the internet community we all engage in, and I'll be looking for a strategy that lets me stay involved as an individual.

<liam> [Matt, a month before you leave, contact me about invited expert status]

<dlongley> manu: Your work here has been invaluable, thank you very much and looking forward to continue to working with you as an individual.

VCWG Website

<manu> https://www.w3.org/2017/vc/WG/

liam: we've identifed the publishing site as a template, so we stole it.

<dlongley> liam: People said they liked the Publishing group's page so I stole it. Please email me directly if you have any updates (copy working group if you feel appropriate) and let me know about implementations so we can link to them.

liam: please reach out to me about updates. --- especially regarding implementatons.

<JoeAndrieu> looks good Liam! Thanks

<dlongley> stonematt: Liam, is the website in github or somewhere where you aren't necessarily the only editor and others can update?

<dlongley> liam: Yes, and editors have write access as well as me.

liam: site is in git hub. chairs can update

<liam> [ https://github.com/w3c/verifiable-claims]

Data Model Issue Review

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

burn: looking for leaders to drive a discussion on open issues.
... otherwise we may start making assignments

Use Case Domain Discussion

<JoeAndrieu> https://docs.google.com/spreadsheets/d/1sUt7OPv5B_DWa4SQcOl16ZZqLg2URwNPmsEhCrisvxM/edit?usp=sharing

JoeAndrieu: will talk though the high level items as introduction. looking for key uses cases in finance

<ChristopherA> q*

JoeAndrieu: reviewing each of the 5 cases

ChristopherA: some changes in europe that requires people ot have portability of information from one bank to another in GBTR
... may want to review those expectations and work to meet them

going back to issues discussion -- how do we engage?

burn: use the comments on issues. use "@" to poke people, suggest a solution, or reopen a discussion

<Zakim> manu, you wanted to suggest we bring these to WCIG

DavidC: doesn't thnk the bundlign cases makes sense

JoeAndrieu: perhaps - DM supports, but we might want to wave people off

manu: should run some of these by the Web Commerce group to validate w/ Visa and MC, etc.
... their feedback may be that these UC are too high level and need refinement
... evernym is working with some clients in finance. recruiting them as our agents to get feedback would be useful

<nage> +1 to tapping FI experts to help get these details right

- DRAFT -

Verifiable Claims Working Group

06 Feb 2018

Attendees

Contents