RE: Request for informal review of Verifiable Claims WG Charter&In-Reply-To=<56E8721B.40806@digitalbazaar.com>&References=<56E8721B.40806@digitalbazaar.com>

> I am the AC representing Blockstream—we just joined the W3C. So this is my first email to the AC list ;-)
Welcome!  It’s great to see companies doing cutting edge work choosing to collaborate at W3C.

> I've met with IBM about the Hyperledger ledger, and this topic came up several times as problems with existing standards. If not W3C, where?
I was at the Blockchain lunch discussion at the recent AC meeting, and I recall the Hyperledger participants saying the open questions are about “what” to standardize and “when” to do so, not “where”.   (Arnaud should correct me if I misunderstood).

> One of the responses to this review request suggested that "what is lacking in the proposal is
> persuasive evidence that yet another standards effort would have a better outcome this time."
> Unfortunately, the other standards efforts do not emphasize decentralized self-sovereign identity.
> Yet there is clearly an increasing demand for this that I am seeing in the blockchain community
That sounds like a response I made, so let me clarify.  Nobody is disputing that de-centralized identity is an interesting use case or that blockchain technology is a potentially fruitful way forward.  My response is answering the “when” question as “not now” – it’s ready for community building, use case definition, spec brainstorming, prototyping…. But not standardization. W3C has a number of ways to collaborate on on technologies before they are ready for the standards track – Workshops, Community Groups, Interest Groups, Business Groups …and the essence of our feedback is “one or more of the other mechanisms to explore Verifiable Claims at W3C is the right way to proceed at this time.”

In my experience, W3C working groups are seldom successful unless they start with a solid draft spec and participation from those who must implement and deploy a spec for it to be a real standard.  There are exceptions that started from a “blank sheet of paper” such as XQuery https://en.wikipedia.org/wiki/XQuery, but that process took from WG formation in 1999 until the first Recommendation in 2007. Plus that WG had strong participation from the commercial database vendors as well as key open source implementers, and had 3 co-chairs with long track records in database standards.    I don’t see either of these preconditions – solid draft spec and/or really strong community of the likely implementers – in the Verifiable Claims proposal.  That’s doesn’t mean it will never be ready for a WG, just that it’s not YET ready IMHO.

You’re free to disagree of course and persuade the team and other members to start a WG, but consider:  the formal Working Group process is historically better at polishing rough specs than forging new ones. The WG process implies that those who don’t like a proposal can/should formally object and block progress until everyone agrees to a way forward or there is guidance from the W3C Director. There are better ways of handing the high-level architectural disagreements that are inevitable in the early stages of a project.  For example, the Web Platform Incubator Community Group http://wicg.github.io/admin/charter.html  defines its decision process as follows:

It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer. With that said, the group favours forward motion and dissent will not be allowed to block work on a spec.

If substantial disagreement remains (e.g. the group is divided), the Committers will continue with their preference. The issue should be recorded as decided without consensus. Individuals who disagree with the Committer's choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.

This is just how things work in one community group, but it is based on the experience of numerous open source projects, including (I believe) those that build 3 of the principal browser engines.  The Verifiable Claims community is under no obligation to adopt that sort of conflict resolution policy, but it’s worth carefully considering and learning from how it works in the WICG and the OSS projects that build much of the web infrastructure, as the community decides how to pursue its vision under the W3C umbrella.


From: Christopher Allen [mailto:ChristopherA@blockstream.com]
Sent: Wednesday, April 6, 2016 12:04 PM
To: w3c-ac-forum@w3.org; public-webpayments-comments@w3.org
Subject: Re: Request for informal review of Verifiable Claims WG Charter&In-Reply-To=<56E8721B.40806@digitalbazaar.com>&References=<56E8721B.40806@digitalbazaar.com>

On Tue, 15 Mar 2016 16:35:39 -0400, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

This is an *informal* request to review the Verifiable Claims Working

Group charter. This charter is NOT under W3C Membership review yet.



In short, the work is about expressing and exchanging cryptographically

verifiable proofs of age, driver's licenses, passports, and

educational/professional qualifications via the Web.



We are sharing this charter now because a few of us that have been
I am the AC representing Blockstream—we just joined the W3C. So this is my first email to the AC list ;-)

Some background: I was the co-author of the TLS 1.0 standard that drives internet commerce security today, so I am long familiar with standards processes and have been successful facilitating them. More recently I also have been working with Oasis XDI standard to help them break some centralized underpinnings that they have identified have prevented their broad deployment. The company I work for, Blockstream, is one of the leading companies in the blockchain space, with some of the top cryptographers and cryptographic engineers in the world. Personally I have multi-decade commitment to identity, for instance I'm on the steering committee for the ID 2020 Summit http://www.id2020.org at the United Nations in May, as well as technical design workshops with some of the top engineers in the world, the next one after the ID 2020 Summit in NYC.

Part of the reason that Blockstream has joined W3C is that we are very concerned about architectures of centrality in identity services. We are care deeply about privacy and respect for the human and civil rights of the individual. What the Verified Claims group calls "user-centric" is what we call decentralized self-sovereign identity. We believe that there is a place for centralized approaches, but there is also an increasing need to support decentralized approaches. We wish to support both.

One of the responses to this review request suggested that "what is lacking in the proposal is persuasive evidence that yet another standards effort would have a better outcome this time." Unfortunately, the other standards efforts do not emphasize decentralized self-sovereign identity. Yet there is clearly an increasing demand for this that I am seeing in the blockchain community (not just permissionless like Bitcoin, but permissioned efforts by large banks and other fintech institutions). For instance, I've met with IBM about the Hyperledger ledger, and this topic came up several times as problems with existing standards. If not W3C, where?

Another response was "some governments are unlikely to trust credentials that are not received directly from the agency responsible for issuing them." That may be true, but our customers are often peers, not governments. This include C2C, B2C, B2B and other relationships. We have significant uses cases for federations of banks across multiple borders that need decentralized solutions where any one government can't issue identity. In the short term, there is some real need for better identity tools for the developer community which can bootstrap this project. We don't need browser support today—long term as we prove what can be done I can see interest from them, but browser support should not be a requirement for moving this WG proposal forward.

There was another response that "W3C community should be skeptical of spec efforts that don’t have real skin in the game". Though we have interest in the Web Payments Group, the principal reason why were have joined W3C is to support the Verified Claims project. We anticipate that we will be supporting ~1 FTE engineer and security architect to support these efforts, maybe more.

I also have spoken in the last few weeks to some other startups about considering joining W3C to support these efforts. At least 2 are seriously considering it, maybe more. Even though they are startups, like us they have large amounts of VC funding to move forward these efforts. I will also be reaching out to my contacts IBM, Intel, Cisco and other blockchain community members that have W3C membership somewhere else in their organization, to talk with their W3C AC about supporting this effort.

Finally, Homeland Security has granted two different organizations SBIR research grants on decentralized identity on the blockchain to companies that I am partnered with. The fact that HS is financing this research is another demonstration that this WG should move forward.

-- Christopher Allen