The Verifiable Claims Task Force

A Task Force of the Web Payments Interest Group

Verifiable Claims Telecon

Minutes for 2016-12-06

Agenda
https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Dec/0002.html
Topics
  1. Introduction to John Koshy
  2. Rebooting Web of Trust, Paris
  3. Issue Prioritization
  4. Use of JSON/JSON-LD in spec
Organizer
Manu Sporny
Scribe
Gregg Kellogg
Present
Gregg Kellogg, John Koshy, Christopher Allen, Manu Sporny, Matt Stone, Drummond Reed, Eric Korb, John Tibbetts, David Ezell, Jonathan Holt, Rob Trainer, Nathan George, David I. Lehn, Adam Lake, Colleen Kennedy, Adam Migus
Audio Log
Gregg Kellogg is scribing.

Topic: Introduction to John Koshy

John Koshy: I’m a freelance consultant working in healthcare in the D.C. area.
… When the ONC invited whitepapers we responded about how the blockchain can help reduce administrative costs. That’s where I met Manu. Looking forward to learning from this community and helping where I can.

Topic: Rebooting Web of Trust, Paris

Christopher Allen: I’ve been hosting such conferences that a number of members of the VC community have atteneded. The last three were in the US, the next in Paris on April 21 (fri-sun). To continue moving forward the agenda.
… We’re oriented towards being a customer of VC for self-sov solutions.
Manu Sporny: I’m wondering if we should try to organize a VC F2F with Rebooting. I agree with ChristopherA that there’s been a great amount of cross-fertilization. We have IIW and Rebooting WoT initiatives.
Christopher Allen: IEEE S&P is Wed-Fri after #RebootingWebOfTrust
Christopher Allen: Mon Tue would be good
… Because we’ve had the meetings in the US, and because TPAC is in Burlingame in 2017, it might be good to have an F2F in Europe.
Christopher Allen: 24Th - 25th is right before IEEE S&P
Christopher Allen: We’re trying to get this funded by sponsors and be at a retriet center. In lieu of that, it may be at the old stock exchange.
… David Robert is the contact. If you want to have space surrounding that, the Mon-Tue could be arranged.
Matt Stone: In terms of timing, if we get the approval in January for the WG, is April a reaesonable time?
Manu Sporny: Yes, it’s in the middle of the year, and good time before TPAC. PhilA was right that WGs don’t really get going until people get together, but we’ve already done that, so April is probably okay.

Topic: Issue Prioritization

Matt Stone: How do we want to prioritize issues?
Manu Sporny: We have a number of issues so far. It’s nice to see discussion over the last week.
… Now we have ~27 open issues, and we need to start catagorizing and prioritizing. The best I’ve seen a group do is about 8 issues in a call, and that’s when there’s no discussion necessary. With discussion, just 1-2 per call.
… Given what we have, this could be a year of discussion.
… The WG hasn’t started; when it starts, there may be members not here now; they may request opening old issues.
… For example, the decision around JWT or LD Signatures; that could take many months to get to a decision.
… Editorial issues can be handled more easily. We should prioritize things that aren’t at risk for being re-opened.
… JWT had a lot of discussion, but it’s too early to resolve.
… There are about 15 issues around privacy, which will be long-term discussion topics.
… There is also a question of we should keep JSON and JSON-LD are separate? Should we de-emphasize the -LD bit?
Drummond Reed: +1 To their being no simple issues when it comes to privacy
Eric Korb: +1 JSON-LD
Manu Sporny: Categories aren’t there yet. Usually the chairs and staff monitor discussion and figure out which issues to work on each week.
… That’s not done with tags. Some WGs have tried to create “sprints” using milestones. How the group manages that is up to chairs and staff.
… We may want to have a wiki for chairs/staff to describe priorities, and keep it updated.
Gregg Kellogg: Face to face meetings can be very effective of processing issues. [scribe assist by Manu Sporny]
Matt Stone: F2F is a great way to deal with the more "gnarly" issues - organize to hit them in April at the meeting
Gregg Kellogg: We should really try to grease the skids for an April face-to-face so we have a chance of coming through there by getting through more gnarly work items. [scribe assist by Manu Sporny]
Matt Stone: We should work on that in the 2-3 meetings before the F2F.
Christopher Allen: I’d like to prioirtize things we can close early, so we can get work done.
… I’m in the midst of comissioning people to begin to use the proposed formats to do some real demos. I recognize that everything could change, but I’d like to settle some of these things early: Using JSON, using some kind of signature for that.
Matt Stone: I think that’s good for the group to get implementors started, so that in 9 months we can show movement.
John Tibbetts: Still working on it
Manu Sporny: Just to agree with Christopher, as you may know, Digital Bazaar has implemented much of this. If there is something that’s blocking folks from implementing, we want to get that cleared first.
… At the end of the day, a spec is useless if there aren’t implementors that are implementing. If we have implementors demanding resolution, we should work hard to get these things settled, and get the spec and test suite updated.
Matt Stone: +1 On supporting implementors
… That said, what’s blocking you now?
Christopher Allen: I’d say that questions about canonicalization. I’d love to say we’re going to do JSON-LD, but if not, I need to know sooner rather than later.
… I can survive with a format that’s not RDF, but I need to know sooner rather than later.
John Tibbetts: I want to be sure that before we go too far about JSON vs -LD, I strongly feel we need to pursue the -LD bit, but I think there are some tactics we can use to make it more tollerable.
… I’m suggesting we soft-pedel some of the LD parts, as not everyone needs that level, but it’s important to preserve as a basis for the technology.
Christopher Allen: I want to draw a distinction… We need a strategy for how to deal with those that come back with issues on JSON-LD, but I’m confused on how to do it.
Manu Sporny: Fundmentally, implementations win; if implementors don’t follow the spec, the spec doesn’t matter.
… What Christopher asked is about C14N, and would like to resolve this. Note that we left C14N out of the charter, as it was/is a lightning-rod, and we’ve been blocked on that.
… The reason we did that was for implementors to have a chance outside of the standards process on what they like, and handle that in round-2.
Eric Korb: For those needing a definition, in computer science, canonicalization (sometimes standardization or normalization) is a process for converting data that has more than one possible representation into a "standard", "normal", or canonical form.
… The reason we did that was to allow implementors more options. That discussion is between people like ChristopherA, and whoever is doing implementations. We’ll get together outside of the standardization process and figure out what to use. The W3C process is too slow when trying to do implementations and deploy.
… The short answer is that we’ll need to nail C14N outside of the WG, and give the WG heads up as to where we are. If there are three companies doing C14N in a specific way.
Matt Stone: If that’s our strategy, are those discussions fair game for these calls?
… 2ndly, Pierson is working in this area, if we’re working outside this call, what’s the best way for us to do this.
Gregg Kellogg: The Credentials CG still exists and can be an ongoing forum for these WG discussions. That's the purpose of the CG [scribe assist by Manu Sporny]
Gregg Kellogg: I wanted to react to Manu's strategy to keep canonicalization out of spec, get to them in a next round, I worry that that's being quite optimistic. Timeframe doesn't do a good service to the community. It's really hard to get a WG done, usually after a WG has completed, there is usually not a big appetite to get back to it. It might be five years before another WG is created to have a remit to deal with canonicalizatin. Is there a way to keep it in as a [scribe assist by Manu Sporny]
Manu Sporny: Stretch goal so a WG could react to implementation experience.
Manu Sporny: I think we’re in a difficult place with digital signatures: the current implementors have decided on JSON-LD and LD signatures, but the JWT community have pushed back.
… The concern is that we were being blocked before, and was a no-go from W3M. It would seem that W3C is stomping on the IETF territory.
… That said, you’re points are spot-on. I think it will happen anyway; it wasn’t on the agenda today, but we’re talking about it anyway.
Matt Stone: At a minimum, we’ll deliever what’s in the charter. As we go into that, this will be part of the implementation. It seems it will be at the table one way or another, even if the spec covers it.
… JWT group can complain, but if it’s in the field that’s the effective standard.
Christopher Allen: Prove we can do it with JWT and demonstrate it, then I’ll be glad to consider it.
Matt Stone: +1 On put up or shut up...
Manu Sporny: To put a pin in this, I’m not too concerned that we’ll get to the end of the WG and not know about how to do this. Both Christopher and Matt are right: put up or shut up, and look at implementation experience.
Matt Stone: Is this, in fact the JSON/JSON-LD discussion?
Gregg Kellogg: If the group thinks this will be part of hte process later, particularly in the test suite we HAVE to have room in the charter now to include it later [scribe assist by Matt Stone]
Matt Stone: We’ll need to come back to this when we review the charter. There may be a honeymoon period were we can address this.
… Do we want to add uncertainty?
Manu Sporny: Text in the charter right now: "Signature Mechanism(s): that are capable of protecting the verifiable claims from attack such that the claims can be trusted by consumers of those claims."
Gregg Kellogg: +1
Drummond Reed: That's a good, concise summary of the requirement.
Manu Sporny: I think we’re in the clear, but we can’t invent a new format; however, we can recommend something that exists in the field.
… The WG can then point to something that exists and say “do that”!

Topic: Use of JSON/JSON-LD in spec

John Tibbetts: The spec has a section on JSON and another on JSON-LD, and they’re identical, except for @context. This happens in several different sections.
… It seems to me we should _only_ specify the JSON-LD approach, rather than side-by-side. With language saying that it is completely valid JSON.
… People worry that they’ll get lost in the -LD parts, but it’s really not an issue practically. We can discuss differences in an appendix.
… People look at this, and only think of it in terms of JSON, the @context is just template. You really don’t need to worry about the -LD parts for most practical uses.
… Some people do need to worry about this, if you’re creating a signature algorithm, or designing the basic structure, but if you’re just consuming, you rarely need to know about this.
… What I’m suggesting is that we just talk about JSON in the sense that it’s constrained to work as -LD.
David Ezell: I just got back from ISO in Paris, where there’s a move to go from XML to JSON.
… One of the ideas is using HATEOS.
… To me, it doesn’t seem much different than JSON-LD, other than syntax.
… I think it’s going to be important to come up with JSON in the payments space.
Manu Sporny: Example of a stronger stance on usage of JSON-LD: https://www.w3.org/TR/annotation-model/
Manu Sporny: There are other groups having the same discussion, and have ended up in two different places. The Web Annotations group came up with a strong stance on the use of JSON-LD.
… There was a big disagreement in the Activity Streams group.
Manu Sporny: Social Web WG comments on use of JSON-LD: https://www.w3.org/TR/activitystreams-core/#syntaxconventions
… The social web group did something that might meet both requirements. The data format is JSON, but you need to be able to interpret it as JSON-LD, which allows it to be machine readable, and allows people that just want JSON
Matt Stone: 2Min time check...
Christopher Allen: I’m sympathetic to just pulling out that part, and have a different document for C14N. But, my experience trying to do DiD where it was pointed out the JSON we were specifying would have a problem with the graph model, and how it could be simply modified to do this.
… Without saying graph-model, can we put enough constraint to make sure we don’t break it.
Manu Sporny: Short answer, right now, we don’t know what those constraints might be.
John Tibbetts: Had to drop off for another call
… You’re either saying tree-model or graph-model. By default JSON is tree-model. We don’t know how to convey these constraints right now.
Drummond Reed: +1 To RDF graph model constraints feeling strange to most JSON developers
Drummond Reed: But they may be necessary