W3C home > Mailing lists > Public > public-credentials@w3.org > October 2016

Re: Verifiable Claims Charter Proposal prepped for W3M

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 2 Oct 2016 15:14:51 -0400
To: Credentials Community Group <public-credentials@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
Message-ID: <57F15CAB.5020502@digitalbazaar.com>
On 10/01/2016 07:39 AM, Varn, Richard J wrote:
> Why was self-sovereign deleted

Short answer: We don't need it in the charter, we have it in the charter
motivations document and I think that's good enough.

Long answer:

We were asked to remove the Problem Statement and Goals sections
(repeatedly) because there was concern that W3C Members reading the
charter would become confused regarding the Intellectual Property
(patent) commitments they were being asked to make. Groups that are not
narrowly scoped (or seem like they are not narrowly scoped) tend to take
a very long time to get through the AC Review process. This is because
W3C Members that want to join the work don't want to overcommit their
organization's IP rights (patents). We want a large group of
organizations to join because of the patent pool that's created as a
result. The larger the patent pool, the less susceptible the work will
be to patent assertions over time (in theory).

The charter is supposed to give the lawyers a clear idea of the sort of
IP Review their organization should do before they join the group. If
the lawyers think that the IP commitment is unclear or onerous, they'll
suggest that their organization not join the work or they'll request
that the wording is clarified so that the IP commitment for their
organization is clear.

We have endeavoured to clarify the patent commitments by moving the
problem statement and goals section to a supporting document. Doing this
makes it a bit less clear what the motivation for the work is in the
charter, but if a reader were to assert that "this has been done before"
or "SAML should be enough", then we can point to the charter motivations
document and assert why the answer isn't as simple as "Just use SAML".

> why are we making suggestions instead of recommendations?

Short answer: "Recommendation" is a term of art at W3C that means
something very specific, and we were using that word in the wrong way in
the charter.

Long answer:

The word "Recommendation" is a term of at in the W3C that means that a
document is a "Technical Recommendation". That means it went through the
multi-year First Public Working Draft -> Candidate Recommendation ->
Proposed Recommendation -> Technical Report process. For the specific
document (Verifiable Claims Implementation Guidance) where we changed
the word "recommendation" to "suggestion", we don't want to go through
that process because it would be premature to do so. The implementation
guidance document should state "We think you should do X, and Y, and if
you want to deploy Verifiable Claims via SAML or OpenID Connect, then
you may want to think about A and B."

At the end of this process, we're striving to get the data model and a
few syntaxes down. We may be able to recommend a signature format or
two, but we may fail to do so. We're probably not going to be able to
recommend how this stuff should be used in SAML or OpenID Connect
because it'll be too new. We need to wait for deployment feedback for
that to happen and 2 years is not enough time to deploy and get enough
feedback to then provide a technical recommendation on specific
deployment scenarios. What we can do, however, is postulate how the
technology might be deployed. To put this another way, we can't speak
authoritatively on how this stuff should be deployed at the protocol
layer because doing that is out of scope. What we can do, however, is
setup the next phase (which may be protocol work) based on where we end
up with the data model and syntax.

Did that help?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built
Received on Sunday, 2 October 2016 19:15:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:42 UTC