AI KR approaches toward solving DID Formal Objection Status Update (Dec 2021)

Dear CG
cc Manu S, Fabien G


I am sharing the email below with the AI KR CG because it provides an
update on a concrete issue in hand, and it summarises a real use case which
i relevant to AI KR, and somewhat to wider ontological demarcation
challenges which lie at the heart of AI KR.

I would be interested to see how AI KR approaches,
including RDF/SHACL which is purported to be useful in some respects, could
offer towards overcoming this DID bottleneck

Should anyone be interested to brainstorm around KR solutions approaches
please share your thoughts and suggestions to convene

I take this opportunity to send warm Season's greetings all ye all

PDM
---------- Forwarded message ---------
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, Dec 5, 2021 at 12:42 AM
Subject: DID Formal Objection Status Update (Dec 2021)
To: W3C Credentials CG <public-credentials@w3.org>


Hi CCG-ers,

This email contains the full-text of a "status update" letter that I sent to
the W3C Advisory Committee (all 450+ W3C Member company representatives)
earlier this week, on behalf of the DID WG.

As a reminder, we have a DID Formal Objection FAQ that goes into more detail
on each item below:

https://msporny.github.io/2021-didwg-formal-objection-faq/

-------------------------------------------------------

Dear Advisory Committee Members,

Most of the DID Objectors and a number of Members of the DID Working Group
have been in communication with each other over the past few months in an
attempt to understand the Formal Objections in depth and produce concrete
proposals that might achieve consensus. We have made some progress, and this
email summarizes the current state of the discussion.

Below are described the current points of contention, addressing which will
require additional concrete proposals:

Standardizing "Truly" Decentralized Methods
-------------------------------------------

There seems to be general agreement among the objectors and DID WG that a
good
future state would be to have a handful of "truly decentralized methods"
that
are standardized and broadly adopted. The challenge is that there is no
concrete proposal among the objectors or the DID WG that would achieve
standardizing a set of "ideal" DID Methods in the near term, because there
is
no agreement on what "truly decentralized" means. This challenge was one of
the reasons why standardizing DID Methods was explicitly out of scope for
the
first iteration of the DID WG. At least one of the objectors believes that
to
have been a mistake, but will have to concretely articulate how whatever
alternate path they propose will lead to a better or more guaranteed
outcome.

The definition of "truly decentralized methods" was a topic of discussion
for
much of the DID Working Group's lifetime, and the discussion produced the
DID
Rubric which lists over 36 different types of decentralization that one
might
consider when selecting a DID Method. The WG asks that the objectors be
concrete in defining which types of decentralization matter to them in a way
that will result in consensus for the DID WG re-chartering process.

Usefulness of DID Core, by Itself, as a REC
-------------------------------------------

At least one of the objectors believes that the DID Core specification by
itself is not useful enough to publish as a REC because it does not
standardize at least a few "truly decentralized methods". The DID WG
believes
that DID Core by itself is useful as a REC today because it enables software
libraries to be written that conform to the DID Document data model
(rotatable/revokable public key expression and service descriptions) as well
as the interface for resolving a DID Document using a DID Document Resolver.
This is the sort of interoperability that the WG targeted and what the test
suite demonstrates today. Standardizing the interfaces that the DID Document
provides is useful in and of itself. Further standardization of "truly
decentralized methods" will also be useful for instructing implementers on
how
to interact with the ecosystem, but that must be done with great care to
ensure that we do not prevent other decentralized methods. It's not that we
don't have options; it's that consensus around those options remains elusive
for a variety of political and technical reasons as demonstrated by the
formal
objections.

The DID WG asks that at least one of the objectors be concrete about why
they
don't believe it is useful to publish DID Core as a REC. The DID WG
understands that at least one objector wants us to show "more" interop, but
concretely articulating that more interop is possible at this time is
challenging because 1) the objections contain conflicting requirements, and
2)
there is no consensus around what "truly decentralized" means; those that
utter the phrase appear to mean it to be an objective measure, but upon
analysis, it tends to turn into a subjective one. Nevertheless, the
objectors
will need to make the case why the DID WG and implementers are misguided in
their request for publication as a REC and why DID Core, by itself, is not
useful enough for it to become a REC.

Practical Usefulness of did:key and did:web
-------------------------------------------

At least one of the objectors does not believe that did:key and did:web
demonstrate the sort of utility that is practically useful. The DID WG
believes that did:key and did:web are useful. A number of implementers make
use of did:key for ephemeral DIDs in production settings, while did:web
offers
large institutions an on-ramp into the DID ecosystem without having to
commit
to a "truly decentralized" DID method.

The DID WG was planning to standardize did:key and did:web for practical
reasons (people do use these DID Methods, which do exercise most features of
DID Core), but the Formal Objections have made us question whether we could
put those DID Methods into a charter that wouldn't receive further Formal
Objections because they're "not decentralized enough". The DID WG asks that
objectors propose concrete alternatives to did:key and did:web that will
achieve consensus during the rechartering process of the DID WG.

Centralized DID Methods
-----------------------

Many of us (objectors and DID WG members) do not want to support the
registration of "centralized" (by some definition) DID Methods. However, I
expect that we all understand that we can't stop centralized DID Methods
from
existing, just as we cannot all agree on which factor(s) outlined in the
rubric define "truly decentralized" methods, and it's better to document the
reality of the entire ecosystem than pretend that part of it doesn't exist.
We
could refuse to register centralized DID Methods, but then we must make the
whole "is it decentralized enough" value judgement when people try to
register
their DID Methods, which often does not come down to an objective measure.

If any of the objectors would like to pursue this, the DID WG would need to
understand what concrete set of objective requirements we could apply to all
DID Methods to draw a clear line between "centralized" and "decentralized".
Given the hours of discussion this topic has received in the DID WG, I
expect
it will be difficult for the objectors to put forward concrete objective
criteria that the group has not already considered.

Sustainability and Conflict Within Ethical Web Principles ("EWP")
-----------------------------------------------------------------

As a general rule, the objectors and the DID WG care about sustainability
and
the W3C Ethical Web Principles[1] (EWP). The DID WG would like concrete
guidance from the W3C TAG, such as updated sections in the Web Platform
Design
Principles[2] that are more thoughtful about balancing conflicting EWP
requirements, such as may arise between sustainability and innovations in
PKI[3] to support digital human rights. Part of this discussion mirrors the
"decentralized enough" issues highlighted above. What is "compliant enough"
from an EWP sustainability or EWP freedom of expression perspective?  When a
solution exposes conflict between various principles, then what is the
priority of each principle? What is the burden of proof to demonstrate the
magnitude of the effects of any concerns? These questions are larger than
the
DID WG.

Our hope is that the objectors' concrete guidance here is going to be the
same
as ours — create guidance that firmly addresses how EWP are to be measured
across all W3C specifications and then apply that evenly to all W3C
specifications. This is too important to be done piecemeal in a single W3C
WG
that is not holistically focused on the EWP or the Web Platform Design
Principles.

--------------

I hope this summary of the current state of discussion helps those that have
an interest in the DID Core Formal Objections. Corrections, comments, and
questions are encouraged.

On behalf of the W3C DID Working Group,

-- manu

[1] https://www.w3.org/2001/tag/doc/ethical-web-principles/
[2] https://www.w3.org/TR/design-principles/
[3] https://en.wikipedia.org/wiki/Public_key_infrastructure

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/