[EDITOR'S DRAFT] Demonstration of Support for Verifiable Claims Working Group

During May 2016, the Verifiable Claims Task Force performed a survey among 91 organizations to determine if the Verifiable Claims Working Group proposal had industry support. The response rate to the informal review of the Verifiable Claims work was 62% (high for an optional survey), with 56 organizations responding to the survey.

A summary of the findings follow, with detailed aggregate statistics for each question and response throughout the rest of this document. Raw data is available as HTML and CSV.

Summary of Findings

• 56 organizations responded (out of 91 that were polled).
• 93% supported the Verifiable Claims Problem Statement and its accuracy.
• 96% supported the Goals proposed by the Verifiable Claims work and asserted that they were good goals to pursue.
• 87.5% agreed that the Scope of Work and Deliverables would help address the Problem Statement.
• 64% felt that their organizations use cases were included in the highly focused list of use cases that the Working Group should consider.
• 35 organizations said that they would actively participate in the work. The breakdown of those organizations are:
  • 17 W3C Members committed to participating in the work (out of around 40 that were selected to be contacted).
  • 10 organizations committed to joining W3C if the work was started.
  • 8 organizations said that they would perform periodic technical reviews of the work but would not join W3C (due to budget/bandwidth concerns).

Negative Responses to the Work (in general)

• Three long-term W3C members have suggested that the work should be incubated further before entering the standardization process.
• A few individuals noted that they were concerned about the general area of the work.

Positive Responses Categorized by Organizational Size

• 16 large multinational for-profit corporations with multiple billions of dollars per year in revenue responded positively to the charter.
• 10 large trade associations / standardization groups, several with hundreds of members and tens to hundreds of billions of dollars in collective revenue, responded positively to the charter.
• 27 small organizations with less than 250 employees responded positively to the charter.

Problem Statement

Goals

Scope of Work

Use Cases

Participation

Reasons for Not Participating

If your organization would NOT participate, what changes would we have to make to the draft charter to change your mind?

• A focused workgroup on the educational credentialing system partering with IMS Global, OpenBadges, and HR OpenStandards.
• Its a question of money, not technical scope
• We would participate. This is very important work.
• We support the charter. Participation is based on available resourcing to-be-determined.
• I'd monitor the progress. I'm not quite sure what kind of vocabulary you intend to develop, and whether it will be relevant to the problems we're trying to solve at [REDACTED].
• N/A
• Dependent on client
• We prefer to set up a CG to incubate specifications first, instead of WG.
• We agree that there are interesting problems worth exploring here, but aren't convinced that the area is mature enough to charter a WG.
• No focus on payments or financial value exchanges. Non-repudiation, consensus mechanisms, etc. "Credential Repository" should be a permissioned public ledger technology where the data can only be appended/updated but never deleted. Permissioned public ledger allows self-assertions and major providers to sign those assertions.
• Prioritization of use cases around starting with largely excluded populations.
• I'd like to see a requirements model as an output of the work

Suggestions

Is there any other input that you have on the Verifiable Claims Draft Charter?

• Verifiable Claims is critical for our involvement with W3C (is the major reason why we joined last week).
• Need some way to express the confidence associated with the verification - level of assurance
• All input that I have has been previously incorporated into the documents.
• Please reconsider the word 'rich' in goal three. In my interpretation, from a user perspective the verifiable claim should not be 'rich' but 'just enough' to prove what needs to be proven. E.g. prove of age over 18 to by wine, the claim doesn't need to provide age, name, gender, whatever, but only the hash/prove (not to be manipulated) of 'over 18'. I believe it should be 'appropriate' or 'tailor made' for the purpose it serves."
• Insist on the ability for claims issuers to controle who can request a claim; insist on the objective to rely as much as possible on existing W3C standards (eg for data models)
• Good luck and best wishes!
• I am already working on an implementation that satisfies the goals of this group, using FIDO as the underlying technology.
• Very pleased with the application across multiple domains (e.g., financial, education) including the rapidly growing credentialing marketplace for workforce-related credentials
• The semantic issues surrounding the interoperability of verified claims, particularly on an international basis, could be given more emphasis in the charter—this is one of the major stumbling blocks to interop that other efforts have not overcome.
• Relating VC to Hardware Systems doing similar things with e.g. SmartCards
• The NZ government has implemented an attribute brokering pattern where the verified claims exist at attribute providers independently from the service providers. While some attributes are managed by a single authoritative source, for others the user can potentially select the attribute provider for the credential information passed to a given service provider. Although we would not strongly agree with the second item in the problem statement, we support the potential benefits of the overall verifiable claims initiative.
• There is broad interest in solving these problems in the education community, and a number of techniques being developed by vendors. Strong standardization of a technology path could focus the interest and effort from a wide variety of investors in education.
• No. Looks good. Nice job.
• Identity is always in the context of a domain. Self-asserted information is not that useful, and not that hard to convey. If a user can get access to the information asserted by a domain, and perhaps get a permanent record of that data, it could be useful. I think there is some overlap with the Open Badge specification: http://openbadgespec.org
• Conssider Blockchain if suitable
• We prefer to set up a CG to incubate specifications first, instead of WG.
• No, thank you.
• We will need to coordinate well and use the wisdom of various past and existing identity efforts and security protocols. I think the network layer will need to addressed to deal with MITM attacks or another way found to address that which we can do.
• More clarity about supporting infrastructure assumptions.
• Many of our [REDACTED MULTI-HUNDRED-BILLION DOLLAR INDUSTRY ASSOCIATION] members are concerned that "generic" schemes for VC are less than what is needed for Payments. These sentiments come mainly from folks involved in X9/ISO standards.
• The scope of this charter is somewhat too limited; we understand that it is an initial effort, but a standardized complete ecosystem for claims is necessary.
• The use cases as expressed are interesting, but we would prefer to see a clearer expression of the overall user need - to what degree is the lack of verifiable claims the most important (or most tractable) area of friction in any of the processes described?
• We are concerned that pulling the work out as a standalone working group will lead to excessive abstraction. If this is a particular need to enable concrete improvements for payments we would prefer to see a proposal emerging around payments and then look for broader application.
• An ongoing community group, working in parallel with the payments work, might be a good forum for tracking other developments in this space and informing whether the situation changes, for example from the emergence of practical implementations."
• It would be good for accessibility to be recognised in the use cases guiding this work. The ability for someone with a disability to confidently verify themselves offers a degree of trust that is simply not obtainable at present.
• There isnt a single financial use case in the document yet Payments is all over the doc. KYC is not even a use case, its barely mentioned in the use cases as a scenario. Financial Services is an after thought. Additionally, verifiable claims shouldnt be another "schema". It should be child schema's within other schema's such that the VC data structures are consistent across many schema's (VC data model within other data model's). If we must "exchange" VC it must be in-band with the existing information system formats (such as ISO 20022). However, identity/credentials dont change everyday so a more linking to semi-static blob/ledger of permissioned data would be more appropriate than identity information flying all over the place.
• Scenarios should also include, person with no gov't issued id able to generate a history and use that history as a form of verifiable claim of identity. Pseudo anonymous.
• In my opinion the Charter defines a good approach to user-centric verifiable claims. In the Netherlands, a service-centric scheme (iDIN) has just been launched, which shares some use cases with VC. For the bank, the current vision is based on service-centric related income. In order to address that, a separate NOTE on business models would be useful
• Looking forward to continued collaboration.
• Nice work!
• Prior to finalizing any recommendations, I think the group should fully explore, document, and verify the requirements the system is designed to address. The current use case document is a good start, but more work should be done to assure alignment with both existing and anticipated related efforts. Also, I think a claim can and should be more broadly defined to cover any assertion by an author about a subject.
• We're grateful for Manu's help reviewing the [REDACTED] protocol and helping us with JSON-LD. We're moving as aggressively as possible to finalize the next version of the protocol.