Re: Verifiable Claims Telecon Minutes for 2016-12-06

Hi All,

I've been working on a conference agenda to be delivered in April, at the
WWW Festival in Perth, Australia[1][2] which will be held in the largest
convention centre in Australia[3] providing an opportunity where several
thousand may Attend.  The program facilitates several 'colocated
conferences' whereby it is my intention to produce what i am calling the
'Trust Factory' event.

Reviewing the teleconf. from last night, i understand the group is now
looking to arrange a F2F later in April.  In-turn discussion of The Web of
Trust[4] workshop has led me to introduce what i have been working on
earlier than i had otherwise planned.  It is my view that should the
proposed F2F occur in Perth, following the related conference agenda i have
been working to set out, the program of work would benefit significantly
overall.

I am of course open to collaborative development for the broader schedule.

ABOUT THE PROPOSED EVENT

'Trust Factory' is about the future of socio-economic participation by
persons.  It is an inclusively produced schedule seeking to obtain
representation from every industry to introduce those who would never have
been involved with W3C standards work or participation to speak about the
influence claims, influence their sectors in which they specialise; and how
as they become digital and verifiably so, the operation of their businesses
are expected to change.

The really simple bit gets down to the future of 'digital resumes' and
certainly also, education.

The schedule intentionally has some proposed sessions that seek to assist
people in understanding what the W3C is and the role it plays, as distinct
from 'custom solutions' (for instance).  Other sessions seek to introduce
the concepts pertained within the wording 'web science' alongside an
introduction to 'linked data' (in consideration that many of the industrial
needs for participation moreover relate to the production and use of
ontologies).

The proposed final session is an ambitious goal of having a debate about
'digital identity', where i'm currently separating the groups into (latin)
'Homo Sapiens' vs. 'Persona Ficta'.

This schedule aims to encourage participation and W3C Membership for the
array of industry identities who would not have been involved with W3C in
former eras.

The schedule is very much directed as the future of Verifiable Claims; and
it is my suggestion / hope, that you may facilitate the more technical
discussion emboided within the proposed web of trust[4] and related
conference schedule discussed in last-nights (2am my time i think from
memory) teleconference[5].

I will need to learn of your views within the next few days.  The working
document (on google docs) is available via google docs[6] and given the
status of the document, i'm providing people access on an as-needed basis.
Those who request access from this group will be provided it, but i'm not
publishing atm.

I'm still working on things more broadly.

I am able to help people understand how the ticketing and other related
matters will work for this proposed event.  The website (trustfactory.org)
is in development.  I was sincerely hoping we might internationally
collaborate on this undertaking.  In essence, we're working on important
matters that will effect the socioeconomic participation of persons into
the future.  Not many of us at the moment, yet certainly more than a few
years back.

Timothy Holborn.
+61 4 13837492
skype: sailing_digital



[1] http://www.www2017.com.au/
[2] http://www.festivaloftheweb.com.au/
[3] https://en.wikipedia.org/wiki/Perth_Convention_and_Exhibition_Centre
[4] http://www.weboftrust.info/
[5]
https://lists.w3.org/Archives/Public/public-credentials/2016Dec/0017.html
[6]
https://docs.google.com/document/d/1FB-GbH9X3n-Tu1WJkHmdOd2R1d7n76mEUEepPHTqnK0/edit#


On Wed, 7 Dec 2016 at 04:34 <msporny@digitalbazaar.com> wrote:

> Thanks to Gregg Kellogg for scribing this week! The minutes
> for this week's Verifiable Claims telecon are now available:
>
> http://w3c.github.io/vctf/meetings/2016-12-06/
>
> Full text of the discussion follows for W3C archival purposes.
> Audio from the meeting is available as well (link provided below).
>
> ----------------------------------------------------------------
> 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:
>   http://w3c.github.io/vctf/meetings/2016-12-06/audio.ogg
>
> 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
>
> Manu Sporny: https://github.com/opencreds/vc-data-model/issues
> 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
>
> Manu Sporny: https://github.com/opencreds/vc-data-model/issues/27
> 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.
> Christopher Allen:
>   https://jeffknupp.com/blog/2014/06/03/why-i-hate-hateoas/
> 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
>
>
>
>
>