Dan Burnett: Agenda is https://lists.w3.org/Archives/Public/public-credentials/2017Jan/0024.html ✪

Dan Burnett: Comments or suggestions on the agenda? ✪

Dan Burnett: Manu, can you give us an update on the Working Group vote status? ✪

Manu Sporny: The vote is over; we did well. The W3C staff is now talking to the organizations that formally objected. They asked for some information from us, particularly around privacy. ✪

Manu Sporny: Have we responded to privacy concerns, will we continue to respond etc. We sent them a list of links going back to 2011 where we have worked to address privacy concerns. ✪

Manu Sporny: Don't know when this process will be over. ✪

Dan Burnett: Any other questions on the status of the creation of the Verifiable Claims Working Group? ✪

Dan Burnett: https://github.com/opencreds/vc-use-cases/issues/33 ✪

Dan Burnett: We'll time-limit this discussion. Manu and Joe are the two who are going to have the first comments here. ✪

Joe Andrieu: This started out as simply another way to represent the tasks in the use cases. Specifically to upgrade and expand the "sequences" we have. This is how I do it in my practice. What came out of this exercise for me were some questions about architecture and protocol. These are somewhat outside our charter, but the questions were hard to answer without at least a strawman. ✪

Joe Andrieu: From a requirements standpoint, it seemed like a distributed ledger would at some point be necessary, made it seem like an architecture section is necessary ✪

Manu Sporny: The idea of converting sequences to essential narratives seems good. Waiting on you, Joe, to take the next step ✪

Manu Sporny: On revocation, there has to be some work on the data model side on how to express revocation. Some work has been done on this. Nate Otto (ottonomy) and Badge Alliance/Open Badges have done some work on RevocationLists as one method. ✪

Manu Sporny: Do we want as part of the verifiable claims work to specify how revocation is handled? ✪

Manu Sporny: One thing we can put in a credential is a "place to look up revocation information". ✪

Manu Sporny: One approach is to say this is out of scope, to say that here's a revocation url but it's up to you to figure out what's at the end of that list. ✪

Manu Sporny: Those are at least two of the questions in front of us about revocation? Do we want to express it in the group / do we specify a specific protocol? ✪

Manu Sporny: I think you got the descriptions right in the narrative got it right. ✪

Manu Sporny: I'll stop there. We have a couple decisions about what we want to support in the group and how far we want to spec this out. My company will be implementing ledger-based revocation and url/http-based revocation in the next 6 months. We'll have experimental proposals for the group to see if they want to bring any of these approaches in. ✪

Dan Burnett: Could you say a little bit more about how to point to an external object for revocation? ✪

Manu Sporny: In the current certificate authority system we have a system for certificate revocation lists. This is a format for certs that have been revoked by a CA. We're effectively talking about the same thing, so part of this is to see if we can use the same format. Or if a new format that's a better fit for VCs. ✪

Dave Longley: We shouldn't assume that there is just one way to do revocation. There may be varying needs for different levels of privacy or etc. What we should be able to do is express information in the credential itself to describe what type of revocation method is used. ✪

Nathan George: +1 ✪

Jonathan Holt: I pitched this to the american board of medical specialities. There's some differences about how this would like to be expressed... ✪

Adam Migus: I agree with everyone here. I don't think we've done a complete job if we "scope out" revocation. Need to have at least one way in scope for the project. ✪

Dan Burnett: I'm not hearing any disagreement with putting revocation into scope. ✪

Dan Burnett: I think we knew that anyway, but it's nice to have it reviewed here that we agree that it's in scope. ✪

Manu Sporny: I do want to hear from Nathan George and Nate Otto ✪

Manu Sporny: The next steps for issue #33 is about converting sequences to essential narratives: Let Joe convert the doc to this format. ✪

Manu Sporny: We should take this revocation thing and move it to its own issue. ✪

Manu Sporny: We need to create an issue in the data model to add a section on revocation. ✪

Nate Otto: Yes, Badge Alliance and Open Badges Spec, moved to IMS Global, we do have a notion of revocation list, and hosted revocation. [scribe assist by Manu Sporny] ✪

Nate Otto: We have two ways of verification of revocation... ID that is HTTP based for revocation... go fetch document, use whatever you found as canonical document, if there is a property revoked=true, then it's been revoked. Most people only publish that property. [scribe assist by Manu Sporny] ✪

Nate Otto: There is also a signed assertion version, you can use a revocation list where there is a Linked Data document that contains an array of revoked assertions, if you find a revoked assertion, then you can assume it's revoked. you can find revocation reason. From this experience, not all platforms are going to want to use the same method of revocation, we wanted to keep spec open to things like ledger-based revocation in the future. [scribe assist by Manu Sporny] ✪

Nate Otto: If they are using signed verification - they may be sensitive to hosting costs, so ledger based may be the way to go in the future there. [scribe assist by Manu Sporny] ✪

Nathan George: A lot of our revocation story is centered around the idea of anonymous credentials. About whether data is included or not included in a specific claim. We can extend that story to cover credentials that are not presented as an anonymous credential. Would like to cover how revocation is covered in a "did"-like object. ✪

Dan Burnett: Manu, you had volunteered to create a new issue for the data model? ✪

Manu Sporny: Sounds like we are creating a new section in the data model for revocation. Sounds like we don't want to say there must be only one way. I'll volunteer to write this section. ✪

Nate Otto: Yes, I can help put that together ✪

Dan Burnett: Make sure to put forward and back references to what we have. ✪

Dan Burnett: When you create the issue, link to #33 and from #33 ✪

Manu Sporny: Will do. ✪

Dan Burnett: Any other questions/comments/discussion on either issue #33 or the topic of revocation, creating a new revocation section. ✪

Dan Burnett: https://github.com/opencreds/vc-data-model/issues/12 ✪

Dan Burnett: I think it was the same two people on this one. ✪

Joe Andrieu: This started out initially as an open question about how we deal with correlation in the privacy section. I made some notes, but I'll skip them, because they're not what the issue became. Adrian added what I call a "use domain". ✪

Joe Andrieu: How do you talk about these usages that are really several transactions in a system. ✪

Joe Andrieu: What came out was a discussion about correlation. Questions for me came up like, "What's the architecture?" How can we talk about correlation of different entities in these transactions. Adrian's language didn't necessarily break it out in terms of architecture and components. ✪

Joe Andrieu: We still have this open issue for how we want to talk about the architecture in this document? How do we want to talk about correlation (and preventing correlation) in our data model so we can nail down privacy impacts of verifiable claims? ✪

Manu Sporny: I think the use case was super helpful from Adrian to help narrow down all the types of anti-correlation that we want to build into the system. It's also clear that we can't do anti-correlation in some of these scenarios. Pure URL approaches will correlate strongly... other approaches like using pseudonymous signatures in other cases will preserve your privacy. ✪

Manu Sporny: Not sure where we go with this. Two things we have to do in WG: Enable a privacy-enhancing non-correlatable way of doing this (minimum bar in the data model). Question: can we suggest any standard way to do this -- while these technologies are still in development, haven't gone through security review. ✪

Manu Sporny: Best we may do is say in the spec that it is desired that these be non-correlatable, but provide a warning for pitfalls that make them correlatable. ✪

Manu Sporny: Then outside the group, work on things like group signatures, anonymous signatures, ... things that plug into the spec and without any modification to the spec improve people's privacy. ✪

Manu Sporny: For now, we should specifically point out what actions lead to correlatability. ✪

Dave Longley: We should say "unintentionally correlated" ✪

Dan Burnett: Adrian are you on the call? ✪

Dave Longley: Since correlation is both a goal and something to avoid ✪

Dan Burnett: S/burn/JoeAndrieu/ ✪

Adrian Gropper: I'm tracking what's being said. Glad to try to help. Not at a point where I can relate this in terms of the technology, but let's keep at it. ✪

Jonathan Holt: Great use case, well documented. While this is my niche, it's a heavy lift. ✪

Jonathan Holt: Let's start off with a simple use case, with this global vision in mind. This is less of a use case than a "use domain" or a "vision". We're not quite there to apply this technology to make sure we completely enable privacy from the get-go. ✪

Joe Andrieu: I mentioned that in both the issues we talked about, a desire to have some straw man architecture/protocol, even though that's outside of scope. Maybe we can do what we did for revocation about how we talk about this within the documents. ✪

Joe Andrieu: Vision: This pharmacy has its domain of trust, this doctor has its domain of trust. We want the Pharmacy to not be able to make certain correlations, but others might need to... Need a description of architecture in this document. ✪

Manu Sporny: What type of architecture, and which document? ✪

Joe Andrieu: I have asked for an architecture in general for all verifiable claims (what are our assumptions about all verifiable claims). For revocation, I can address what I need by using a "url, where there may be something". Some of these other use domains need some circles and arrows to explain the different actors, or the different domains of trust. ✪

Jonathan Holt: +1 ✪

Manu Sporny: Trying to get to next step here. Last thing you said hit the nail on the head. We haven't documented the privacy domains. I don't think we're there yet, but we can do a privacy-and-security analysis on Adrian (agropper's) use case. We're all pushing toward something where you're not correlatable, but if we take specific scenarios and apply the spec as we have it, we'll be able to say what the privacy implcations are. If we do this enough times, we may come up with a general case, but let's only generalize after we start to see patterns from specific cases based on the VC spec we have now. ✪

Adrian Gropper: I think in terms of privacy engineering -- to your comment about this being a "use domain": given that privacy engineering is a field, it would be useful to bring that document into the conversation that joe introduced us to whether we're developing a use case or use domain. ✪

Dave Longley: +1 To manu's suggestion ✪

Dan Burnett: Any objections to proceeding with manu's suggestion, starting with agropper's use case? ✪

Nate Otto: +1 ✪

Dan Burnett: We do need people to do that though. The discussion was "We could do this"... Who would be willing to work on that? ✪

Jonathan Holt: I do ✪

Adrian Gropper: http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf ✪

Adam Migus: Sign me up ✪

Joe Andrieu: I can help, this is the next step to this work, but I'm not familiar with agropper's term of privacy engineering ✪

Manu Sporny: I volunteer to help w/ the privacy analysis for Adrian Gropper's use case. ✪

Adam Migus: (I know enough about NIST privacy engineering to be *very* dangerous). :-) ✪

Jonathan Holt: It's about documenting the stakeholders. Understanding the technology that's used in a position. I'm with the american board of medical specialties, and this is a cumbersome process right now. Need first understanding the landscape of players, then the technical landscape. ✪

Adrian Gropper: I volunteer as well ✪

Jonathan Holt: I can help understand the stakeholders and document that. The privacy engineering field will have specific angle. I can help with documenting the stakeholders, but this is a heavy lift. There are background players, like employers (providers of health insurance..). It' s about understanding the flow of information in the state of the art and identifying opportunities for privacy enhancement. ✪

Nathan George: I've been through all these data flows before (developed medical data products prior to my work at Evernym), and can also participate as needed ✪

Dan Burnett: JoeAndrieu, will you oversee this and get it started? ✪

Joe Andrieu: I think this is going to be more than a one hour chat and we're done. ✪

Joe Andrieu: Should we set up a call? ✪

Dan Burnett: Every time we talk about privacy, there are other aspects that come up? Worry that we wouldn't have the right person on a breakout call when that happens. ✪

Joe Andrieu: Meant to propose a call on "Use Cases" generally, not just this task. ✪

Jonathan Holt: +1 ✪

Dan Burnett: We have what we need to proceed for this issue? Thoughts on proposal from Joe for separate Use Cases call? ✪

Manu Sporny: We're suffering from telecon-itis. Though we want to help...... ✪

Manu Sporny: See your point, want to agree. Will have trouble carving out time on a regular basis. Wondering how to help without volunteering to attend another telecon. Could we just continue in GitHub and just tag a bunch of people who volunteered? Or just one call to make a gameplan then move to async in the issue tracker? ✪

Joe Andrieu: I take your point. ✪

Jonathan Holt: +1 ✪

Joe Andrieu: You guys have lots of calls, looking at the larger community of conversations going on here. We could try moving this forward on GitHub, or have an initiating call to establish a framework and then tease out the details on GitHub. I'd like to (at least) do that. As part of my conversation with agropper there was some good back and forth, but I'm not sure I've grasped the whole domain. Maybe take a call to frame the domain and then move to GitHub. ✪

Jonathan Holt: Great solution. ✪

Jonathan Holt: If we have one call to hash out details, then move to github. This is a great domain to "solve", if we solve this one, other solutions may come from it. ✪

Shane McCarron: "A Repo-Man's life is always intense" ✪

Dan Burnett: Do you need something longer than an hour? We could dedicate next week's call to this for the kickoff meeting. ✪

Manu Sporny: I noted volunteers here: https://github.com/opencreds/vc-data-model/issues/12#issuecomment-274862221 ✪

Joe Andrieu: That would be great. Save me the trouble of organizing a different time on people's calendar. ✪

Dan Burnett: Any objections to using next week's telecon for that? ✪

Joe Andrieu: And lets keep the github moving forward as well ✪

Dan Burnett: Will connect with you on agenda, to let you take it over. ✪

Manu Sporny: Question for you, Dan: At some point, we should talk about those of us who will be implementing over the next 6 months... test suite... requirements. ✪

Dan Burnett: I'll be talking with the other chairs later this week about what would be a good way to address that. We'll be sending some thoughts out to the list within a week or so. ✪

Dan Burnett: We're at the end of our "above-the-line" items for the agenda. ✪

Dan Burnett: JoeAndrieu, is there anything else you're aware of in the issues that would be good for productive discussion for 10 minutes? ✪

Joe Andrieu: In vc-data-model privacy issues, several are near duplicates: #11 & #12, #6 & #7 ✪

Joe Andrieu: Make sure we get everyone's pet use case on the list of what's dealt with. ✪

Shane McCarron: +1 To that ✪

Manu Sporny: Along those lines, JoeAndrieu, I think we've been talking about healthcare and education for a bit, but the VC work was kicked off and started by the Web Payments IG. They care about things like digital loyalty, coupons, offers. From my perspective those are all verifiable claims. JoeAndrieu, do you feel these retail use cases are well represented in the doc? I'd hate to get into the group and not have these use cases present for people who are not yet at the table (in some cases, they have their own group for Digital Offers). Those have been use cases for a long while, the reshuffling to focus on focal use cases, we may have lost a few of those retail/commerce use cases. ✪

Shane McCarron: We had lots of use cases about finance in the document I edited... ✪

Jonathan Holt: That is my concern as well that we are doing a "push" into healthcare, when there currently is a "pull" in the web payments domain. ✪

Joe Andrieu: Yes we did; The only two retail we have are young use cases. Adult beverages... Manu what I'm hearing is we need to overall review whether we have the domains we want to focus on. In those domains, do we have the use cases that matter to those domains? ✪

Joe Andrieu: Under retail, we only have address verification and adult beverages. ✪

Manu Sporny: This is a problem to only have so little for our organization. I want to at least want some of these (loyalty, offers) in the document so people can't say we ignored it. We're not coordinating with the Digital Offers group enough. Would like to cross pollenate, so we can hear their use cases. Get more of those people into this group beyond dezell and myself. ✪

Dave Longley: Offers: "you can buy this for X", loyalty: "you are loyalty member X", receipts: "you bought this for X, it's your proof-of-purchase", discounts/coupons: "you can buy this thing at a reduced rate" or "you can buy two of these for the price of one" ✪

Manu Sporny: It's Digtial Offers (this thing, this price), digital coupons, loyalty cards, digital receipts (which will be raised soon in WP IG as point of interest). Web Payments IG working on 2017 vision now, having face-to-face in Chicago in March. Would be good to get some of this work fed back to the WP IG especially on digital offers. ✪

David Ezell: I agree that Digital Offers should be front/center in terms of use cases. ✪

Dan Burnett: I want to hear some of the comments from others, as we're getting short on time. Want to make general statement that it's easy sometimes when (this effort spun out of payments, so payments group may think we know what they need), but at some point soon we need to prioritize what we work on. Priority is likely to be based on those who are participating in the group. ✪

Dan Burnett: Before dezell panics, this is not saying use cases from payments are not important, but more of a motivation for that group to keep participating. Participation will be what ensures we can focus on that work when we start prioritizing. Any prioritization we do now will be redone/reshuffled when the WG starts anyway. ✪

Joe Andrieu: Previously, I suggested bringing in domain experts in each of these domains. Is there a way to do that for the domains we're addressing in healthcare, finance, retail, (education). Is it a good process idea to try to corral specific people? ✪

Dan Burnett: It's fine to invite people you think will help us move forward. If they're difficult to get, find a week they might be able to attend and let's work it into the agenda then. ✪

Joe Andrieu: More like identifying people who are already in the conversation. "I want to work with YOU on HEALTHCARE" "I want to work with YOU on FINANCE". Are there people in our conversation already we can earmark? ✪

Adam Migus: Please consider me an SME for financial services ✪

Dan Burnett: Good discussion; we're at the end of the hour. ✪

Dan Burnett: Let's table that for the moment. Not quite sure where to put it. Very important question about how that should work. Let's talk offline, JoeAndrieu about a good way to incorporate. ✪

Dan Burnett: Thank you very much. ✪