Re: Support for Verifiable Claims

Is a standard designed or does it evolve as a result of collaboration
between implementers to standardize what they have already incubated?

That seems to be the debate underlying this thread.

Respectfully, I think the larger browser vendors prefer the incubation
approach because for the majority of cases at W3C this does work best, for
them. The set of implementors is small, their participation at W3C is
extensive and when they incubate something they have the size, on their
own, to influence the whole market. Further, they generally have the
resources to assign at least one person to almost every WG so their
influence across the consortium is significant.

So, while every member has only one vote, setting a bar that says forming a
WG happens only on the back of an incubated ecosystem is a way to ensure
only the large members ever form a WG. For smaller members without the
resources to seed an ecosystem their only hope is to propose work that the
large members are also interested in pursuing or that is so uninteresting
it slips past them unnoticed.

Further, I don't believe the answer to my initial question is finite.
Effective standards development happens across a spectrum of different
processes appropriate to each case. In the case of most Web standards where
the implementers are a well known, small set, of large, multi-national
technology companies with the resources to incubate the work first then
incubation makes sense.

But, there are exceptions to this where the likelihood of a coherent
standard emerging out of independent efforts is low and the implementors
are diverse. Sometimes the technology being standardized is sufficiently
abstract, or cuts across such a wide range of industries that trying to
take all of the incubated, or existing implementations and extract a
standard is far less efficient than designing the standard upfront.

I hear concerns that attempting to seed an ecosystem through
standardization is wrong and I ask, "Why?" and "Based on what evidence?"
Sometimes some basic primitives that everyone has agreed upon up front are
the only way the ecosystem will ever be built. Sometimes standardization is
the reason the ecosystem exists at all. All I hear to the contrary are
anecdotal assertions.

I agree that sometimes these efforts fail, but so do incubation-first
initiatives. Rather than preventing these initiatives from starting
shouldn't we try to find better ways to evaluate if they are succeeding
while the WG is doing it's work? We should be more accepting of a WG
forming and then shutting down after a short time with no output if we
determine that assumptions made in the charter have not turned out to be
true.

We should also accept that when these kinds of up-front standardization
efforts are undertaken it is natural for stakeholders to be cautious about
throwing resources into the work until a reputable body like W3C has given
the group their endorsement.

In fact, the larger W3C members often rely on their own brand and their own
endorsement of a project to grow the ecosystem around that project. We have
all been part of those technology decisions where a particular code library
or technology is chosen because "that's what Google use" or "it was
developed and is maintained by Facebook's open source team".

Given the effort the Credentials CG and the Verfiable Claims TF has gone
through to demonstrate that they a) have the ability to deliver a well
designed standard and b) are solving a real problem I fail to see why
endorsing this group by forming a WG is such a problem, especially if the
detractors have no intent in participating in the work. (I'll note also
that the Credentials CG has incubated this work to death and has been told
repeatedly that they can't form a WG on the back of such opinionated
technology choices so they have paired down their initial scope to almost a
shell of what it was before)

I think what this thread illustrates is that work by a sub-group of members
can never get off the ground (even if the impact to the members that don't
wish to be involved or agree with the work is basically nil) as long as
that sub-group doesn't include one of the W3C super-powers.

Unless these members are being dishonest about their reasons for blocking
the work I can only assume that they are doing so because they fear the
overhead of forming the group is a waste of W3C resources. However, by that
argument all of the members that are interested in forming the VCWG should
formally object to the formation of any other WG until such time as the
resources ARE available to form the VCWG.

All members have a single vote and voting for a WG to be formed should not
be done in isolation. Forming a WG, like undertaking any project at any
company, must be weighed up against other projects and a prioritized list
of work must be decided upon. Given that the W3C has a limited pool of
resources the vote each member gets is actually a vote for the priority of
a proposed piece of work as opposed to a vote in favour of or against the
work purely on the merit of it's likelihood of success or failure.

I.e. When a member votes on some work they should consider a) does this
group appear likely to acheive it's objectives AND b) how important is this
work in relation to other proposed work on the W3C roadmap.

In the case of Verifiable Claims I think it's clear that this is extremely
important work that not only makes a lot of sense to be done at W3C given
the technologies that are involved but is also a critical piece of a
variety of other initiatives related to identity that are being dealt with
across education, payments, civil society, health care and more by small
companies like Digital Bazaar to national bodies like the Estonian
government, right up to the United Nations.

Therefor, if this work continues to be blocked on the back of a small
number of objections from a minority of members who feel it does not
justify allocation of W3C resources, then I believe it is the right of the
other members to ensure it gets the priority they feel it deserves, by
blocking any other work that is using up those resources.

This is clearly not a situation we want to get ourselves into in the long
run but I fail to see, given the current policies, how the smaller members
can ever exercise their rights to do work that they feel is important.

My hope is we will find a way to make forming (and most importantly
closing) a WG a more lightweight process so that opposition to forming a WG
is far less common and the grounds to shut down a non-delivering WG more
clear and easily executable.

If a WG like the VCWG forms on the promise of wide participation by an
ecosystem of stakeholders waiting for the W3C's endorsement of the work,
then it should be possible to easily measure if that promise is being
delivered upon, and if it is not then the W3C should have a mechanism to
shut the WG down without wasting further resources or endorsing any output
of the group.

On 3 November 2016 at 15:15, 刘大鹏(鹏成) <max.ldp@alibaba-inc.com> wrote:

> Hello all,
>
> I agree that Verfifiable Claims would provide help for disabled people.
>
> It could also be useful for production traceability etc.
>
> I am in favoer of this work moving forward.
>
>
> Regards,
>
> Max
>
> Alibaba
>
>
> On 16/10/2016 17:19, Shane McCarron wrote:
>
> > Spec-Ops has reviewed the proposed charter for a Verifiable Claims
> > working group.  We are in favor of this work moving forward, as we
> > believe a common structure for claims is essential to jump-starting a
> > universal environment for digital verification.  We look forward to
> > contributing implementations and tests to this working group as its
> > recommendations progress.
>
> TPG echoes these comments from Spec-Ops.
>
> The task of independently verifying oneself is difficult (or impossible)
> for many disabled people. Current methods often require people with
> disabilities to relinquish any degree of privacy and/or to share
> personal data insecurely. The ability to provide verification digitally
> has enormous potential to change both these things.
>
>
> Léonie.
>
>
>
> --
>
>

Received on Thursday, 3 November 2016 15:57:46 UTC